Target 32 Bit or 64 Bit native DLL depending on environment

Question

I have a native DLL which comes in both 32 bit and 64 bit versions (x86). I want to create a wrapper which works on both architectures (Any CPU) and loads the correct version of the DLL depending on the current environment (32 Bit or 64 Bit, at runtime!). This process should happen automatically, so that the users of my DLL do not need to target a specific architecture.

Are there any best practices on how to do that? Any examples that could guide me?

I found one possible solution that uses managed proxies for each architecture and then uses the Assembly.Resolve event to load the correct version. However this requires me to have 3 managed assemblies in addition to the 2 unmanaged libraries, which seems a bit overkill.

Is there any other solution?

http://scottbilas.com/blog/automatically-choose-32-or-64-bit-mixed-mode-dlls/ hope it will help. — Ajit Kumar, Apr 22 '14 at 10:12
**Related Post** - [What are the pros and cons of running IIS as 32bit vs 64bit on a 64bit OS?](https://stackoverflow.com/q/507820/465053) — RBT, Apr 17 '18 at 06:25

score 7 · Accepted Answer · edited Apr 22 '14 at 10:58

7

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

edited Apr 22 '14 at 10:58

David Heffernan

601,492
42
1,072
1,490

answered Apr 22 '14 at 10:24

Simon Mourier

132,049
21
248
298

1

Seems to be the easiest way to go, for now. Instead of IntPtr.Size == 8, I will choose Environment.Is64BitProcess though, which makes the intent more clear. Thanks! – aKzenT Apr 23 '14 at 11:16
1

@aKzenT - yes why not, I prefer my code because Is64BitProcess only exists since .NET Framework 4.0 :-) – Simon Mourier Apr 23 '14 at 11:27
This is probably best if the DLLs have different names. But if you can put the DLLs in different directories with the same file name for the DLL name then this is more complex than needed. – David Heffernan Apr 23 '14 at 12:43
@DavidHeffernan - this is arguable. From a deployment / debugging point of view, I find it much easier to deploy everything in a single place w/o subdirs, and it's easier to identify a native DLL bitness just looking at its name (no BadImageFormatException possible) – Simon Mourier Apr 23 '14 at 12:58
1

Well again that depends. It can go either way in my view. Your approach has a lot of boilerplate. And it may be out of your control. Anyhow, if you do want everything in one folder you are indeed led to your approach. – David Heffernan Apr 23 '14 at 13:02

David Heffernan · Answer 2 · 2014-04-22T12:20:53.473

The way I do it is to p/invoke a call to LoadLibrary before calling any of the p/invokes to the library.

Use the bitness of the executing assembly to work out which version of the unmanaged DLL to load.
Then call LoadLibrary to load it passing the full path to the DLL.
Then when you call the p/invokes, the correct DLL is already loaded into the process and the p/invokes bind to it.

This relies on the unmanaged DLL having the same name for both 32 and 64 bit. If that's not the case then you are in trouble. In that scenario you may need to bind explicitly to the DLL by p/invoking GetProcAddress. This is no fun at all. Or you implement the sort of scaffolding that Simon describes in his answer.

score 0 · Answer 3 · answered Apr 22 '14 at 10:18

0

Take a look at the Microsoft.WinAny.Helper and It'a DynamicNativeLibrary class which can help you with what you need.

answered Apr 22 '14 at 10:18

HABJAN

9,212
3
35
59

This project seems very interesting. Especially for its ability to load libraries from a byte array, which lets you embed the native DLLs as resources. Looking at the code though, it is too much unsafe/native code though for my taste and it does not seem to be maintained. Simons solution seems to be simpler for now. Thanks though! – aKzenT Apr 23 '14 at 11:19
3

The name of that library is very misleading. It is not developed by Microsoft! In fact it is developed by @HABJAN which should have been disclosed in this answer. – kjbartel May 14 '15 at 06:52

Target 32 Bit or 64 Bit native DLL depending on environment

3 Answers3

Linked

Related