Change C# DllImport target code depending on x64/x86

by

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.

More Related Contents:

  1. How can I specify a [DllImport] path at runtime?
  2. Embedding unmanaged dll into a managed C# dll
  3. Docking Window inside another Window
  4. Unload a DLL loaded using DllImport
  5. Using a 32bit or 64bit dll in C# DllImport
  6. BadImageFormatException when loading 32 bit DLL, target is x86
  7. Mute/unmute, Change master volume in Windows 7 x64 with C#
  8. How to use [DllImport(“”)] in C#?
  9. How to pass strings from C# to C++ (and from C++ to C#) using DLLImport?
  10. Read a Registry Key
  11. Do you need to dispose of objects and set them to null?
  12. Query on HasMany reference
  13. Interfaces — What’s the point?
  14. C# winforms combobox dynamic autocomplete
  15. How to loop through IEnumerable in batches [duplicate]
  16. Get the value for a listbox item by index
  17. many-to-many with extra columns nhibernate
  18. Creating API that is fluent
  19. SQL Insert Query Using C#
  20. Get Live output from Process
  21. Wrap properties with CData Section – XML Serialization C#
  22. How do I customize ASP.Net Core model binding errors?
  23. How do I get the currently loggedin Windows account from an ASP.NET page?
  24. Split an IEnumerable into fixed-sized chunks (return an IEnumerable where the inner sequences are of fixed length) [duplicate]
  25. SetWindowsHookEx in C#
  26. How can I determine whether Console.Out has been redirected to a file?
  27. No IUserTokenProvider is registered
  28. C# Converting 20 digit precision double to string and back again
  29. Why can’t I do foreach (var Item in DataTable.Rows)?
  30. a constructor as a delegate – is it possible in C#?

Leave a Comment