我正在编译面向x86-64的.NET应用程序;但是，该应用程序引用了一个32位的dll。可执行文件编译正常，但Visual Studio会发出警告：
引用的'path / to / dll'指向与应用程序不同的处理器。
现在，我的理解是您不能简单地将64位可执行文件链接到32位共享库。 .NET（或Windows？）使用什么黑魔法来实现这一目标？
当针对x86和x86-64构建应用程序时，我注意到了相当大的内存占用差异。当动态加载32位dll并开始处理时，64位应用程序的内存占用量将大约增加60 MB（64位为250 MB，而32位为190 MB），而应用程序的内存占用量为32比特应用程序。但是，当dll中的某个代码路径被命中时，这种差异才会很大，但不幸的是，我无法查看dll以查看内部结构。
如何将64位二进制文件链接到32位共享库？ 32位ABI不会阻止这种情况吗？
为什么在将应用程序编译为x86-64架构时，内存占用量会有如此大的差异？
任何其他要解释的信息都将不胜感激。
答案 0 :(得分：5)
x86和x64无法加载到同一进程中。您确定该引用不是AnyCPU程序集，或者32位引用在GAC中没有64位或AnyCPU版本吗？
另请注意，在64位Windows上，System32中的DLL为64位。 32位的是在SysWOW64中。
答案 1 :(得分：0)
.NET（或Windows？）使用什么黑魔法来实现这一目标？
我的理解是它没有。要引用32位dll，您需要在构建时将目标平台设置为AnyCPU或x86而不是x64。
如果您在64位版本的Windows上查看％WINDIR％\ Microsoft.NET，您将在Framework和Framework64下找到2个运行时，Framework64从2.0开始，首先支持它。
经过多挖掘，这里有一个similar question。
为什么在将应用程序编译为x86-64架构时，内存占用量会有如此大的差异？
罗伯特是......错误是正确的（他删除了他的答案:)，更多信息感谢Hanselman，但有other costs too。从我在决定我们的方法时发现的情况来看*大多数人似乎都报告了大约20-40％的内存使用量增加。
*我们的目标是针对.NET的AnyCPU，然后针对x86编译一次Wix（MSI部署），针对x64编译一次。