How to call 32bit library from "Any CPU" assembly? There is one idea.

[Ananas]

Hi,

I work with native code over the PInvoke. The problem is when I link
the 32bit native library I have to switch "Platform target" to x86 to
avoid the BadImageFormatException. At this point my assembly becomes
32bit (=x86) and all assemblies referencing this assembly should also
be 32bit (=x86), otherwise I get BadImageFormatException.

Is it possible in some way to leave the assembly in the x64 world but
link 32bit dll using PInvoke?

I have an idea, but I do not like it. I have created the wrapping
native library on C++ that links another library explicitly in runtime
by LoadLibrary(...). This wrapper is invoked by managed code over the
PInvoke. The assembly, invoking the wrapper, has "Platform target" set
to "Any CPU" and I have no problems with linking it to another
assemblies. But actually I assume there is much easier method.

 

[Jeroen Mostert]

I work with native code over the PInvoke. The problem is when I link
the 32bit native library I have to switch "Platform target" to x86 to
avoid the BadImageFormatException. At this point my assembly becomes
32bit (=x86) and all assemblies referencing this assembly should also
be 32bit (=x86), otherwise I get BadImageFormatException.

Is it possible in some way to leave the assembly in the x64 world but
link 32bit dll using PInvoke?

No. It's an OS limitation. You can't load 32-bit DLLs into a 64-bit process.
P/Invoke will not help you here; unmanaged applications have the same problem.

The only way to do this without changing binaries is to host the 32-bit DLL
in its own 32-bit process, and use an IPC mechanism to communicate with the
64-bit process (for example, COM). But this is very cumbersome if the DLL
isn't already written as a COM server.

The easiest way to solve this is to mark the startup assembly as x86. If the
assemblies it references are marked "Any CPU" they will be dynamically
recompiled to suit the process, and any unmanaged 32-bit DLLs will load.
Note that you do not need to recompile assemblies to achieve this; you can
use the "corflags" utility included in the .NET SDK to mark an assembly
without rebuilding.

Mind you, most applications do not need to be 64-bit and will run perfectly
fine as 32-bit applications on the 64-bit platform. You should only worry
about this if you really need the extra address space 64-bit will give you.

 

[christery]

Found this that might help with where to place files..

There is a Program Files (x86) folder for 32-bit applications. Also,
in addition to the System32 folder, there is a SysWOW64 folder.
Contrary to what the names may suggest, 64-bit operating system
components and shared libraries go into the System32 folder, while 32-
bit operating system components and shared libraries go into the
SysWOW64 folder. (There are no typographical errors in this
paragraph: 64-bit entities go into the System32 folder, and 32-bit
entities go into the SysWOW64 folder.)

After reading that looking for my dos 3.2 installation disks...
desperatly... *smile*

//CY