Linking 32-bit libraries to a 64-bit .NET application and memory consumption

Question

I was compiling a .NET application targeting x86-64; however, the application references a 32-bit dll. The executable compiles fine, but Visual Studio throws a warning:

Referenced assemply 'path/to/dll' targets a different processor than the application.

Now, my understanding has been that you can't simply link a 64-bit executable to a 32-bit shared library. What black magic does .NET (or Windows?) use to accomplish this?

I have noticed a considerable memory footprint difference when the application is built targeting x86 and x86-64. When the 32-bit dll is dynamically loaded and begins processing, the memory footprint of the 64-bit application will be about 60 MB larger (250MB as 64-bit vs 190MB as 32-bit) than if the application is built as a 32-bit app. This difference is only so great when a certain code path in the dll is hit, however, and I can't look into the dll to see the internals, unfortunately.

How is it possible that a 64-bit binary is linked to a 32-bit shared library? Wouldn't the 32-bit ABI prevent this?

Why would there be such a large different between the memory footprint when the application is compiled as a x86-64 architecture?

Any other info to look into to explain this would be appreciated.

Answer 1

x86 and x64 can't be loaded into the same process. Are you sure that the reference isn't an AnyCPU assembly, or that the 32-bit reference doesn't have a 64-bit or AnyCPU version in the GAC?

Also note that on 64-bit Windows, DLLs in System32 are 64-bit. 32-bit ones are in SysWOW64.

Answer 2

What black magic does .NET (or Windows?) use to accomplish this?

My understanding is that it doesn't. To reference a 32-bit dll, you will need to set the target platform to AnyCPU or x86 rather than x64 when building.

If you have a look under %WINDIR%\Microsoft.NET on a 64 bit version of windows you will find 2 runtimes under Framework and Framework64, with the Framework64 starting at 2.0, where it was first supported.

After a little more digging, here's a similar question.

Why would there be such a large different between the memory footprint when the application is compiled as a x86-64 architecture?

Robert is...err was correct (he deleted his answer:), more info thanks to Hanselman, but there are other costs too. From what I found when we were deciding on our approach* most folks seem to report around 20-40% increase in memory usage.

* We ended up targeting AnyCPU for .NET, and then for Wix (MSI deployment) compiled once for x86 and once for x64.