Using a 32bit or 64bit dll in C# DllImport

Question

Here is the situation, I'm using a C based dll in my dot.net application. There are 2 dlls, one is 32bit called MyDll32.dll and the other is a 64bit version called MyDll64.dll.

There is a static variable holding the DLL file name: string DLL_FILE_NAME.

and it is used in the following way:

[DllImport(DLL_FILE_NAME, CallingConvention=CallingConvention.Cdecl, EntryPoint=Func1")]
private static extern int is_Func1(int var1, int var2);

Simple so far.

As you can imagine, the software is compiled with "Any CPU" turned on.

I also have the following code to determine if the system should use the 64bit file or the 32bit file.

#if WIN64
        public const string DLL_FILE_NAME = "MyDll64.dll";
#else
        public const string DLL_FILE_NAME = "MyDll32.dll";        
#endif

By now you should see the problem.. DLL_FILE_NAME is defined in compilation time and not in execution time so the right dll isn't loaded according to the execution context.

What would be the correct way to deal with this issue? I do not want two execution files (one for 32bit and the other for 64bit)? How can I set DLL_FILE_NAME before it is used in the DllImport statement?

Baseman

What is the difference between the 64 and 32 bit dll's? Is there something the 32bit can't do on 64? If so I would just use 32. – Lampyrid

On a 64bit OS, the decision if to execute the code in pure 64bit or WOW64 (32bit emulated) is decided when the program executes. If the program executes in 32bit mode it should use C based dlls that were compiled in 32bit and 64bit accordingly. – Baseman

If you really want to do this, you'll need to bypass the DllImport attribute altogether and load the DLL yourself, manually, using the LoadLibrary, GetProcAddess, and FreeLibrary functions. That technique is discussed here. It's a fair bit of work, though, and rather simple to get wrong. Letting the P/Invoke mechanism do it for you is so much easier. As others have noted, probably not worth it if you can just fall back to the 32-bit DLL all the time as the lowest common denominator. – Karleen

possible duplicate CPU Architecture Independent P/Invoke: Can the DllName or path be "dynamic"? and Set DllImport attribute dynamically – Karleen

Answer 1

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.

Darceldarcey

For maximum readability, I would suggest using the Environment.Is64BitProcess property instead of checking the size of the IntPtr type. Of course, this property was introduced with .NET 4.0, so if you're targeting an older version, it won't be available. – Karleen

This is exactly what I wanted to do. Although there is some overhead in coding, it works and does the job. – Baseman

I'm impressed that worked for you. I found that usually I need one more layer of indirection between the decision and the call. – Rolfe

Answer 2

Here is another alternative that requires that the two DLLs have the same name and are placed in different folders. For instance:

• win32/MyDll.dll
• win64/MyDll.dll

The trick is to manually load the DLL with LoadLibrary before the CLR does it. It will then see that a MyDll.dll is already loaded and use it.

This can be done easily in the static constructor of the parent class.

static class MyDll
{
    static MyDll()
    {            
        var myPath = new Uri(typeof(MyDll).Assembly.CodeBase).LocalPath;
        var myFolder = Path.GetDirectoryName(myPath);

        var is64 = IntPtr.Size == 8;
        var subfolder = is64 ? "\\win64\\" : "\\win32\\";

        LoadLibrary(myFolder + subfolder + "MyDll.dll");
    }

    [DllImport("kernel32.dll")]
    private static extern IntPtr LoadLibrary(string dllToLoad);

    [DllImport("MyDll.dll")]
    public static extern int MyFunction(int var1, int var2);
}

EDIT 2017/02/01: Use Assembly.CodeBase so that it works even if Shadow Copying is enabled.

Quizzical

This is by farmost the most elegant answer, which best fits the question. I successfully adopted this for the FreeImage project .NET Wrapper! Awesome Idea. I have used Environment.Is64BitProcess instead and resolved the Path for the assembly like Kisdeds answer suggests instead. Thanky you very much! – Halliburton

You could also embed both the 32-bit and 64-bit DLLs as resources inside the .NET DLL and extract the right one/call LoadLibrary if you want to have everything packaged up. – Eoin

You may encounter issues if your native dll requires some other libraries. – Byline

And be prepared to have your users constantly sending you reports about moronic anti-malware programs out there flagging your application as malware simply because of the use of the LoadLibrary function. Been there, done that. – Russelrussell

Answer 3

In this case, i should do like this (make 2 folders, x64 and x86 + put the corresponding dll, WITH THE SAME NAME, in both folders):

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();
    }
    [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
    private static extern bool SetDllDirectory(string path);
}

Darrin

Answer 4

There is a static variable holding the DLL file name

It is not a static variable. It's a constant, at compile time. You can't change a compile time constant at runtime.

What would be the correct way to deal with this issue?

Honestly I would recommend just targeting x86 and forgetting the 64-bit version all together, and letting your application run on WOW64, unless your application has a compelling need to run as x64.

If there is a need for x64, you could:

• Change the DLLs to have the same name, such as MyDll.dll, and at install / deploy time, put the right one in place. (If the OS is x64, deploy the 64-bit version of the DLL, otherwise the x86 version).

• Have two separate builds altogether, one for x86 and one for x64.

Ipecac

Agreed, this is definitely the simplest solution to the problem. The overwhelming majority of apps, particularly line-of-business apps, derive no benefit from being 64-bit native. Even if there might be some marginal performance improvements, the increased overhead of 64-bit tends to cancel those out. The other suggestion you make about using the same names for the DLLs and deploying the correct version depending on the system architecture is exactly what Microsoft does with system DLLs. That seems like a good bet, too. – Karleen

Answer 5

What you describe is known as "side-by-side assembly" (two versions of the same assembly, one 32 and the other 64 bit)... I think you will find these helpful:

• Using Side-by-Side assemblies to load the x64 or x32 version of a DLL
• http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx
• http://www.thescarms.com/dotnet/Assembly.aspx

Here you can find a walkthrough for exactly your scenario (.NET DLL wrapping C++/CLI DLL referencing a native DLL).

RECOMMENDATION:

Just build it as x86 and be done with it... or have 2 builds (one x86 and one x64)... as the above techniques are rather complicated...

Dvina

I do not want two applications. That is soooo 90s. – Baseman

@Baseman then follow the links provided, they show some options that are perhaps more like what you want (BEWARE: it gets really complicated)... – Dvina

@Baseman BTW you can build 2 (x86 and x64) and when the installer runs it can determine which of both to install - the user gets exactly one application... – Dvina

There was no 64bit in the 90's so it couldn't have been the 90's :p – Edgaredgard

@Edgaredgard not completely true... both the APLHA and the MIPS architectures had 64 Bit offerings in the 90s... Itanium 64 Bit came 2001 (was developed second half of 90s)... – Dvina

why did microsoft screw this up so badly? now they make sill UI "improvements" in VS like uppercase menu items instead of fixing that crap. – Judie

This has nothing to do with Visual Studio, and it isn't "screwed up badly". You're just doing it wrong. – Karleen

Answer 6

an alternative approach may be

public static class Sample
{
    public Sample()
    {

        string StartupDirEndingWithSlash = System.IO.Path.GetDirectoryName(System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName) + "\\";
        string ResolvedDomainTimeFileName = StartupDirEndingWithSlash + "ABCLib_Resolved.dll";
        if (!File.Exists(ResolvedDomainTimeFileName))
        {
            if (Environment.Is64BitProcess)
            {
                if (File.Exists(StartupDirEndingWithSlash + "ABCLib_64.dll"))
                    File.Copy(StartupDirEndingWithSlash + "ABCLib_64.dll", ResolvedDomainTimeFileName);
            }
            else
            {
                if (File.Exists(StartupDirEndingWithSlash + "ABCLib_32.dll"))
                    File.Copy(StartupDirEndingWithSlash + "ABCLib_32.dll", ResolvedDomainTimeFileName);
            }
        }
    }

    [DllImport("ABCLib__Resolved.dll")]
    private static extern bool SomeFunctionName(ref int FT);
}

Logogram

It should copy the dll make the app spend more time. – Trotskyite

Answer 7

Based on Julien Lebosquain's great answer, this is what I ended up doing in a similar case:

private static class Api32
{
    private const string DllPath = "MyDll32.dll";

    [DllImport(DllPath, CallingConvention = CallingConvention.Cdecl)]
    private static extern int Func1(int var1, int var2);

    [DllImport(DllPath, CallingConvention = CallingConvention.Cdecl)]
    private static extern int Func2();

    ...
}

private static class Api64
{
    private const string DllPath = "MyDll64.dll";

    [DllImport(DllPath, CallingConvention = CallingConvention.Cdecl)]
    private static extern int Func1(int var1, int var2);

    [DllImport(DllPath, CallingConvention = CallingConvention.Cdecl)]
    private static extern int Func2();

    ...
}

public static int Func1(int var1, int var2) {
    return Environment.Is64BitProcess 
           ? Api64.Func1(var1, var2) 
           : Api32.Func1(var1, var2);
}

I think this option scales better if you have multiple entry points in the same DLL for the following reasons:

• The Api32 and Api64 classes are completely the same except for the single constant defining the path to the DLL file. This means that I can just copy & paste the declarations from one class to the other if anything changes.
• No need to specify the EntryPoint, reducing the possibility of typos.

Epicycloid

I think it might be possible to wire this up automatically with a source generator, to avoid having to duplicate the classes and create the boilerplate manually. – Skyler

Answer 8

I have used one of the approaches meantioned by vcsjones:

"Change the DLLs to have the same name, such as MyDll.dll, and at install / deploy time, put the right one in place."

This approach requires maintaining two build platforms though see this link for more details: https://mcmap.net/q/267534/-how-can-you-access-the-visual-studio-solution-level-platform-from-a-c-project-39-s-build-event

Lieb

Answer 9

The trick I use for V8.Net is this:

1. Create a new C# "proxy interface" project with all the defines to switch between the different architectures. In my case the project was named V8.Net-ProxyInterface; example:

 public unsafe static class V8NetProxy
    {
    #if x86
            [DllImport("V8_Net_Proxy_x86")]
    #elif x64
            [DllImport("V8_Net_Proxy_x64")]
    #else
            [DllImport("V8_Net_Proxy")] // (dummy - NOT USED!)
    #endif
            public static extern NativeV8EngineProxy* CreateV8EngineProxy(bool enableDebugging, void* debugMessageDispatcher, int debugPort);

THIS is the project you will reference. DO NOT reference the next two:

2. Create two more projects to generate x64 and x86 versions of the library. This is VERY EASY: Just copy-n-paste to duplicate the .csproj file in the same folder and renamed them. In my case the project file was renamed to V8.Net-ProxyInterface-x64 and V8.Net-ProxyInterface-x86, then I added the projects to my solution. Open the project settings for each of them in Visual Studio and make sure the Assembly Name has either x64 or x86 in the name. At this point you have 3 projects: the first "placeholder" project, and the 2 architecture-specific ones. For the 2 new projects:

   a) Open the x64 interface project settings, go to the Build tab, select All Platforms for Platform at the top, then enter x64 in Conditional compilation symbols.

   b) Open the x86 interface project settings, go to the Build tab, select All Platforms for Platform at the top, then enter x86 in Conditional compilation symbols.

3. Open Build->Configuration Manager... and make sure that x64 is selected as the platform for x64 projects, and x86 is selected for the x86 projects, for BOTH Debug AND Release configurations.

4. Make sure the 2 new interface projects (for x64 and x86) output to the same location of your host project (see project setting Build->Output path).

5. The final magic: In a static constructor for my engine I quickly attach to the assembly resolver:

static V8Engine()
{
    AppDomain.CurrentDomain.AssemblyResolve += Resolver;
}

In the Resolver method, I just load the file based on the current platform indicated by the current process (note: this code is a stripped-down version and not tested):

var currentExecPath = Assembly.GetExecutingAssembly().Location;
var platform = Environment.Is64BitProcess ? "x64" : "x86";
var filename = "V8.Net.Proxy.Interface." + platform + ".dll"
return Assembly.LoadFrom(Path.Combine(currentExecPath , fileName));

Finally, go to your host project in the solution explorer, expand References, select the first dummy project you created in step 1, right-click it to open the properties, and set Copy Local to false. This allows you to develop with ONE name for each P/Invoke function, while using the resolver to figure out which one to actually load.

Note that the assembly loader only runs when needed. It is only triggered (in my case) automatically by the CLR system upon the first access to the engine class. How that translates to you depends on how your host project is designed.

Mairamaire

Answer 10

I think this could help to load the DLL dynamically:

   #if X64    
    [DllImport("MyDll64.dll", CallingConvention=CallingConvention.Cdecl, EntryPoint=Func1")]
    #else
    [DllImport("MyDll32.dll", CallingConvention=CallingConvention.Cdecl, EntryPoint=Func1")]
    #endif
    private static extern int is_Func1(int var1, int var2);

Mostly

note that #if X64 ... is resolved during compilation, and not during run-time – Cinchonism