index > 64-Bit .NET Framework Development > Loading 32bit or 64bit C++/CLI DLL on demand based on system

Loading 32bit or 64bit C++/CLI DLL on demand based on system

Hello all.

I have a managed application working well on both 32bit and 64bit systems, except for a small part, implemented as a C++/CLI assembly, compiled as x86. I'd like to avoid having two distinct packages, one for 32bit systems, another for 64bit systems. Can I assume that the BadImageFormatException I get on 64bit systems will always occur where I create an instance of a managed class that itself references an instance of the C++/CLI managed type?

In other words, I have a class "VistaVolumeControls" implemented in C#, which creates an instance of "VistaVolumeControlsBridge" implemented in managed C++. If I create two C# classes, "VistaVolumeControls" and "VistaVolumeControls64", which respectively reference types "VistaVolumeControlsBridge" implemented in a x86 C++/CLI assembly and VistaVolumeControlsBridge64 implemented in another x64 C++/CLI assembly, even if the main assembly references those two C++ assemblies, code like this will always work, and the C++/CLI assemblies will never get loaded before the actual "new VistaVolumeControls{64}()"?

Code Snippet
if( Environment.OSVersion.Version.Major == 6 )
{
if( IntPtr.Size == 8 )
{
m_volumeControls = new VistaVolumeControls64();
}
else
{
m_volumeControls = new VistaVolumeControls();
}
}
else
{
m_volumeControls = new WmmVolumeControls();
}

Is this a good approach for targetting 32bit and 64bit systems in a single application/package?

Thank you.

slimcode

I'm a stubborn man, so I decided to try my initial solution. My managed assembly is referencing two C++/CLI assemblies, one built for x86, the other built for x64. I have two classes in my managed assembly, one for each type I need to create in the C++ assemblies. I'm creating an instance of only one of them based on IntPtr.Size.

So far, this seems to work well.

slimcode

Even though the CLR doesn't preload assemblies until you use them, AFAIK the JIT will require the type references to be resolved once you enter the method, and therefore the 32-bit assembly will be preloaded and generate an exception in the 64-bit environment and vice versa.

What I recommend is that you force the .NET side to be 32-bit (this can be done with corflags after the build, or with the build configuration in VS), if you really want to use the same package. 32-bit applications can run very well on a 64-bit OS.

Sasha Goldshtein

It feels awkward to force a managed .NET application to always run in 32bit when the .NET framework does a so great job of working seemlessly in 32bit or 64bit. But I guess it's either that, or I have two packages.

slimcode

Well yes, it does feel a bit awkward. Another alternative is to load the assembly dynamically based on bitness. This is even more awkward though ;-)

Sasha Goldshtein

slimcode

This will work, but be careful because if you accidentally cause the wrong type to get loaded and call a method, the JIT will require the wrong assembly to be loaded.

Sasha Goldshtein

How about this:
1. Build 2 CLI/C++ DLLs for different platform (x86 and x64) with SAME assembly name (or same strong name), such as VistaVolumeControls.dll (The code is same and just the compile condition is different)

2. Just need this to create the instance:
m_volumeControls = new VistaVolumeControls();

3. For x86 , deploy the x86 VistaVolumeControls.dll
for x64 , deploy the x64 VistaVolumeControls.dll

Jamebo

You can use google to search for other answers

Custom Search

More Threads

• Connection to Oracle on XP using msdaora

• Deploying 32 bit app on Vista Ultimate 64bit

• advpack error

• Any performance gain by compiling to x64 instead of Any CPU?

• System.Speech on 64bit XP?

• IIS Server on x64 and VS2005

• Can I create DLLs for XP64 using VB.net 2003

• Runtime error while loading DLL on Win64 platform.

• Windows Service crashes without writing to event log (unhandled exception ???)

• NT Framework, .dll