3

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.

2 Answers2

5

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.

bsneeze
  • 4,369
  • 25
  • 20
  • Yes! There is a 64-bit version in the GAC. That'd explain how building is possible. :) I'm assuming that the Visual Studio build process searches the GAC for an appropriate version of the referenced assembly if the linked assembly will not work. Is that correct? –  Dec 11 '09 at 05:45
0

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.

Community
  • 1
  • 1
si618
  • 16,580
  • 12
  • 67
  • 84