Deployment guideline (using regular DLLs)

[a non e mouse]

Is there a deployment guideline or suggestion for how dotnet
applications that include regular DLLs ?
If a DLL is compiled using a 32 bit compiler then the interop fails in
64 bit environments. The solution seems to be to
a) mark the dotnet application as a x86 application forcing it to run
in the 32 bit emulator
b) recompile the regular DLL with a 64 bit compiler
Presumably one needs to have two DLLs which are deployed by an
installer according to the target operating system, but one would have
expected a safer default handling of the situation.

 

[Jeroen Mostert]

Is there a deployment guideline or suggestion for how dotnet
applications that include regular DLLs ?
If a DLL is compiled using a 32 bit compiler then the interop fails in
64 bit environments. The solution seems to be to
a) mark the dotnet application as a x86 application forcing it to run
in the 32 bit emulator

This only applies to Itanium platforms. (Current) x64 platforms do not
emulate 32-bit software, they run it natively (with almost no performance loss).

b) recompile the regular DLL with a 64 bit compiler
Presumably one needs to have two DLLs which are deployed by an
installer according to the target operating system, but one would have
expected a safer default handling of the situation.

Since interop does not link statically, you could always install both DLLs
with the application, test whether you're running as 32-bit or 64-bit at
runtime and copy the appropriate DLL under the expected file name before
doing interop.

This seems more trouble than it's worth, though. What's unsafe about
checking it at install time? People shouldn't expect to be able to move
installed applications to completely different architectures.

Note that if your .NET application does not require the extra memory that
comes with being a 64-bit application (and running under a 64-bit OS already
gives you 4 GB as opposed to 2 or 3 on a 32-bit OS), it's perfectly alright
to mark it as x86 and use the 32-bit implementation throughout. Your
application does not somehow become better when running as 64-bit.

 

[a non e mouse]

Thanks for the guidance. The point was that I presume that native DLL
PIF headers indicate that they are 32 bit and one would expect
the .NET platform to recognize it instead of crashing on the interop
call.



....

 

[Jeroen Mostert]

The point was that I presume that native DLL PIF headers indicate that
they are 32 bit and one would expect the .NET platform to recognize it
instead of crashing on the interop call.

Do you mean it actually crashes, or does it throw an exception indicating
that the image is invalid (which is what I would expect)? The latter
behavior is par for the course when a 32-bit application tries to load a
64-bit DLL (or vice versa) and the runtime can't detect you're going to be
doing interop with an unloadable DLL (interop is fully dynamic, and there's
no equivalent of "static linking").

The .NET framework doesn't analyze the library itself, it relies on the OS
loading mechanisms. You'd basically see the same thing happening if an
unmanaged application tried to LoadLibrary() an incompatible DLL at runtime.
If the DLL were linked instead, the EXE would refuse to load.