Using a 32bit or 64bit dll in C# DllImport
I've found the simplest way to do this is to import the two methods with different names, and calling the right one. The DLL won't be loaded until the call is made so it's fine:
[DllImport("MyDll32.dll", EntryPoint = "Func1", CallingConvention = CallingConvention.Cdecl)]
private static extern int Func1_32(int var1, int var2);
[DllImport("MyDll64.dll", EntryPoint = "Func1", CallingConvention = CallingConvention.Cdecl)]
private static extern int Func1_64(int var1, int var2);
public static int Func1(int var1, int var2) {
return IntPtr.Size == 8 /* 64bit */ ? Func1_64(var1, var2) : Func1_32(var1, var2);
}
Of course, if you have many imports, this can be become quite cumbersome to maintain manually.
Loading a 32-bit dll in a 64-bit process
You cannot load a 32 bit DLL into a 64 bit process. To support this you will have to have two different EXE's, one compiled as 64 bit and one compiled as 32 bit.
If you run the 64 bit process and encounter a 32 bit dump, you'll have to launch the 32 bit version of the EXE to process the dump file. Once it is processed you can use some sort of IPC (Interprocess Communication) mechanism to send the results back to the 64 bit process.
Import external dll based on 64bit or 32bit OS
Can you import them both and make the decision about which one to call via .NET instead?
For example:
[DllImport("32bit.dll", CharSet = CharSet.Unicode, EntryPoint="CallMe")]
public static extern int CallMe32 (IntPtr hWnd, String text, String caption, uint type);
[DllImport("64bit.dll", CharSet = CharSet.Unicode, EntryPoint="CallMe")]
public static extern int CallMe64 (IntPtr hWnd, String text, String caption, uint type);
Target 32 Bit or 64 Bit native DLL depending on environment
Here is the solution I've used on many projects:
- name the 32-bit assembly with a "32-bit oriented name". For
example MyAssembly.Native.x86.dll - name the 64-bit assembly with a "64-bit oriented name". For example MyAssembly.Native.x64.dll
- compile the managed assembly as 'Any Cpu'
- ship everything in the same path
Here is how I declare P/Invoke methods:
[DllImport("MyAssembly.Native.x86.dll", EntryPoint = "MyTest")]
private static extern void MyTest86(MyType myArg);
[DllImport("MyAssembly.Native.x64.dll", EntryPoint = "MyTest")]
private static extern void MyTest64(MyType myArg);
And here is the corresponding 'MyTest' function which is the one I'll always use (the others are here just for correct bitness binding). It has the same signature than the other P/Invoke ones:
public static void MyTest(MyType myArg)
{
if (IntPtr.Size == 8)
{
MyTest64(myArg);
return;
}
MyTest86(myArg);
}
The advantages are:
- you can ship all binaries (DLLs, EXEs, ...) in the same path
- you support 32-bit and 64-bit processes and OSes with the same file layout
- you don't have to resort to Win32 apis for changing dll load path
The inconveniences are:
- you'll have 3 method declarations for 1 'real' method
- you'll loose some CPU cycles because of the bitness test
- depending on your context, sometimes you can't change the native DLLs names, so you just can't do this
Change C# DllImport target code depending on x64/x86
This is primarily a deployment problem, just have your installer copy the right DLL based on the Windows version on the target machine.
But nobody ever likes to do that. Dynamically pinvoking the correct DLL's function is enormously painfully, you have to write delegate types for every exported function and use LoadLibrary + GetProcAddress + Marshal.GetDelegateForFunctionPointer to create the delegate object.
But nobody ever likes to do that. The less painful tack is to declare the function twice, giving it different names and using the EntryPoint property in the [DllImport] attribute to specify the real name. Then test at runtime which you want to call.
But nobody ever likes to do that. The most effective trick is steer Windows into loading the correct DLL for you. First thing you have to do is copy the DLL into a directory where Windows will not look for it. Best way is to create an "x86" and an "x64" subdirectory in your build directory and copy the appropriate DLL into each. Do so by writing a post-build event that creates the directories and copies the DLLs.
Then tell Windows about it by pinvoking SetDllDirectory(). The path you specify will be added to the directories that Windows searches for a DLL. Like this:
using System;
using System.Runtime.InteropServices;
using System.Reflection;
using System.IO;
class Program {
static void Main(string[] args) {
var path = Path.GetDirectoryName(Assembly.GetEntryAssembly().Location);
path = Path.Combine(path, IntPtr.Size == 8 ? "x64" : "x86");
bool ok = SetDllDirectory(path);
if (!ok) throw new System.ComponentModel.Win32Exception();
//etc..
}
[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
private static extern bool SetDllDirectory(string path);
}
Do consider if having the code run in 64-bit mode is actually useful to you. It is pretty rare to need the giant virtual memory address space you get from it, the only real benefit. You still need to support the 32-bit version that needs to operate correctly in the 2 gigabyte case.
Using a 64bit DLL in a 32bit Application
You cannot mix 32 bit and 64 bit code in a single process. So the only way to use mix bitness code is to have more than one process. You'll need some form of IPC to make it work. You cannot do it with DllImport
since that is in-process.
Related Topics
How to Pass Parameters to Activator.Createinstance<T>()
How to Select Only the Records with the Highest Date in Linq
Is Async/Await Suitable for Methods That Are Both Io and CPU Bound
How to Write Logs from Within Startup.Cs
How to Write to Console.Out During Execution of an Mstest Test
Custom Path of the User.Config
Connection Timeout for SQL Server
Differencebetween the Override and New Keywords in C#
Rendering Partial Views Using Ajax
How to Pass an Object to Httpclient.Postasync and Serialize as a JSON Body
Linq Order By, Group by and Order by Each Group
JSON.Net Self Referencing Loop Detected