views:

78

answers:

2

I have to use a c++ dll from an asp .net site. The site will be hosted on both 32 and 64bits environments.

I have a 32 and 64 bits version of the unmanaged dll. How do I import the methods from the correct one according the current server architecture?

EDIT
Like some one posted, this could be handled as a deployment problem. My concern is: the web application consuming this dll is huge and we don't have a deployment document. No one will remember to deploy the correct dll so I'm trying to remove the human factor from the solution :)

+1  A: 

To get the compiler/framework to do most of the work you need to

  1. have multiple build 'platforms' (typically x86, x64 - remove AnyCPU)
  2. set each "platform target" configuration for each build config
  3. we added conditional compilation symbols __WIN32 & __X64

List the different implementations for your functions according to platform, including different dll names if you need to have both installed at once.

#if __WIN32
        public delegate int Move(int target);
        [DllImport("my.dll", SetLastError = true, CharSet = CharSet.Auto)]
#elif __X64
        public delegate int Move(int target);
        [DllImport("my64.dll", SetLastError = true, CharSet = CharSet.Auto)]
#endif

Otherwise you can use loadlib and manage the marshalling yourself.

Greg Domjan
You definitely don't need to marshal yourself.
Ben Voigt
Now you don't just have two unmanaged DLLs, you've also got two different assemblies. Double the problem.
Hans Passant
Sure, I don't like it much either, but it has been the common advice I've found so far that you should make the assmebly processor specific, including on MSDN/forums.
Greg Domjan
Could you post the MSDN forum link? Still a moderator there, I might be able to delete that.
Hans Passant
MSDN forums recommend `SetDllDirectory` here, with `LoadLibrary` as an alternative solution that works on older Windows versions: http://social.msdn.microsoft.com/Forums/en/csharpgeneral/thread/46535653-46e1-4412-a436-b818abfe4b07
Ben Voigt
@Hans: My comment is a reply to Greg, not a request for you to delete. That thread looks like it has good information.
Ben Voigt
Agreed, makes it a deployment detail instead of a programming problem. The comment I already made in the OP. Infinitely better than what was proposed in this answer. Managing the right SetDllDirectory call when you don't actually control the process initialization is a problem that is deferrable.
Hans Passant
@Hans: if I can find it again, lost in the depths of browser history.
Greg Domjan
+3  A: 

Simplest approach would be to give the two native libraries the same filename in two different directories, then adjust your application DLL search path depending on the bitness.

http://www.pinvoke.net/default.aspx/kernel32.setdlldirectory

Ben Voigt
How do you arrange your assemblies so as to call this Kernal function to extend the dll search path before the loading of the assembly that needs the extended search path?
Greg Domjan
P/invoke doesn't cause the native libraries to be listed in the import table where the OS loader will look for them at startup. Instead, it internally calls `LoadLibrary` the first time any method marked `[DllImport]` with that particular library name is called. So putting the call to `SetDllDirectory` in the type initializer (a/k/a class constructor a/k/a static constructor) of the class where the imported methods are declared guarantees it will happen before p/invoke tries to load the DLL.
Ben Voigt
Some other useful information here: http://www.codeproject.com/Messages/1199816/Re-Yuck.aspx
Ben Voigt