You could use .NET 2.0's dynamic P/Invoke feature, and have your own code decide at run time where to look for the unmanaged DLLs. That's what I decided to do, after weeks of a new kind of DLL hell. If you can write static P/Invoke declarations, you can use dynamic P/Invoke. Testing and deployment were far easier for my application when the application itself contained the logic about where to look for, and when to load, unmanaged DLLs. I did *not* want to outsource that logic to the CLR, let alone to the registry.
-----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ron Inbar Sent: Tuesday, June 19, 2007 3:39 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] Loading 32/64-bit unmanaged DLLs Hi, I want to compile my managed assemblies (both DLLs and EXEs) as AnyCPU. I have a small number of unmanaged DLLs, for some of which I have both a 32-bit version and a 64-bit version, and for others I only have a 32-bit version. Obviously, applications that load DLLs of the latter kind must be compiled as x86 to make them run as 32-bit processes on 64-bit systems. Regarding the former kind, I would still like to use AnyCPU rather than compile them twice. I found one way to do this, which is to put the 64-bit unmanaged DLLs under %windir%\system32 and their 32-bit equivalents under %windir%\syswow64, and let WoW64's redirection mechanism take care of loading the right DLL. However, I would like to restrict my installation scripts to my own directories and not put anything under %windir%. Is there a way to use registry redirection to achieve a similar behavior with directories other than %windir%\system32? =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
