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

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, unfor开发者_高级运维tunately.

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.

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.

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.