we use a self-written 32bit C++ DLL from our C# applications. Now we've noticed that when the C# applications are run on a 64bit system, the 64bit runtime is automatically used and of course the 32bit DLL can not be accessed from the 64bit runtime.
My question is: is there a way of using the 32bit DLL? If not, if I created a 64bit version of the DLL, would it be easily possible to let the application choose which one to P/Invoke to?
I'm thinking of creating two helper classes in C#: One that imports the functions from the 32bit DLL and one that imports from the 64bit DLL, then creating a wrapper class with one function for each imported functio开发者_StackOverflow社区n that calls either the 32bit importer or the 64bit importer depending on the "bittyness" of the OS. Would that work?
Or is there another easy way to do things?
You need to make sure that you're only using P/Invoke calls against a 64bit DLL when compiling in 64bit.
One option is to move all of your "methods" into a standard interface (or abstract base class), and provide 2 implementations, one 32bit and one 64bit. You can have a factory method construct the appropriate instance of the class depending on the size of IntPtr.
This allows an "AnyCPU" app to correctly, at runtime, determine which DLL to P/Invoke into, and does work.
Create a helper class that wraps both 64bit and 32bit DLLS, and use IntPtr.Size to determine which to call.
if (IntPtr.Size == 8)
{
Helper.SomeMethod64();
}
else
{
Helper.SomeMethod32();
}
You can flag the .Net app to only target x86 architecture
I had similar problem but it was with Unrar.dll being either 32 or 64bit.
There can be two approaches to make it work:
a)
#if x64
// ... define all x64 imports here
#else
// ... define all x86 imports here
#endif
And compile application for 32Bit and 64bit.
b) Another way was to create an interface for the imports and implement 32 bit and 64 bits versions separately.
If 32 bit, instantiate the 32 bit implementation, else instantiate the 64 bit implementation.
精彩评论