使用 CorFlags 了解程序集标头（为什么我的程序集加载在 32 位地址空间中？）
我发现了相当多的信息，涉及如何根据程序集标头中设置的标志加载 .NET 程序集。 将托管图像上的位翻转到让它们加载正确的位数...似乎建议如果您有如下标题。
PE : PE32
ILONLY : 1
32BIT : 0
它已被编译为“任何 CPU”，我可以期望它加载 32 位 CLR< /a> 在 32 位平台上，以及在 64 位平台上使用 64 位 CLR。这正是我所期望和想要的行为。
不幸的是，在我的 Windows 7 64 位计算机上似乎并非如此。该程序集加载到 32 位地址空间中。我知道我应该能够通过使用 x64 构建来在编译时强制解决该问题，但为什么它首先会做错事情呢？
我该如何解决这个问题？这是我尚未偶然发现的注册表或环境问题吗？
I've found a fair bit of information related to how a .NET assembly should load based on the flags set in the assembly header. Pages such as Flipping bits on managed images to make them load with the right bitness... seem to suggest that if you have a header as follows.
PE : PE32
ILONLY : 1
32BIT : 0
It has been compiled as "Any CPU", and I can expect it to load with the 32-bit CLR on 32-bit platforms and with the 64-bit CLR on 64-bit platforms. This is exactly the behaviour I expected and wanted.
Unfortunately that doesn't appear to be the case on my Windows 7 64-bit machine. The assembly loads up in a 32-bit address space. I know I should be able to force the issue at compile time by building with x64, but why is it doing the wrong thing in the first place?
How can I fix this problem? Is it some registry or environment problem that I've yet to stumble upon?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您没有提及任何关于组装的种类。只有启动程序集决定进程的位数。执行文件。任何 DLL 都必须效仿。
You didn't say anything about the kind of assembly. Only the startup assembly determines the bit-ness of the process. The EXE. Any DLL must follow suit.