.Net中32位与64位差异及项目编译配置问题咨询

嘿，我来帮你把这几个问题理得明明白白，结合你最后补充的操作细节一起说清楚：

这核心是托管代码和非托管代码的本质区别：

• .NET程序集（DLL/EXE）编译出来的是中间语言（IL）代码，不是直接能运行的机器码。当程序启动时，.NET的JIT（即时编译器）会根据当前进程的架构（32位/64位），把IL编译成对应架构的机器码。所以只要你的.NET DLL是Any CPU或者兼容当前进程架构的设置，就能无缝适配，不会有架构不兼容的问题。
• 而C++ DLL属于非托管代码，编译的时候直接生成了特定架构的机器码（要么x86，要么x64）。64位进程无法加载32位的非托管DLL，反之亦然——这就是你遇到的问题，原来的C++ DLL是32位的，改成64位进程后就加载不了，必须重新编译成x64版本。

64位编译的判定依据 #

.NET程序的运行架构，核心由两个因素决定：

• 启动项目的平台设置：比如你把WPF启动项目设为x64，进程就会以64位启动；设为Any CPU的话，要看第二个因素。
• Prefer 32-bit选项：这个选项仅在Any CPU模式下可见——如果勾选，哪怕在64位系统上，程序也会以32位进程运行；如果取消勾选，64位系统上就会以64位进程运行，32位系统上则自动以32位运行。

只改启动项目为x64，其余保留Any CPU可行吗？ #

完全可行！因为其他.NET项目的IL代码会在运行时JIT编译成和启动进程一致的64位代码，和启动进程的架构匹配，不会有兼容问题。不过要注意：如果这些Any CPU项目里引用了非托管DLL，必须确保非托管DLL是x64版本的，否则还是会出现加载失败的问题。

结合你最后补充的操作细节 #

你最后用「所有项目设为Any CPU + 取消WPF启动项目的Prefer 32-bit」的方案非常巧妙：

• 取消Prefer 32-bit后，程序在64位系统上会以64位进程运行，能正常加载你重新编译的x64 C++ DLL；
• 同时Any CPU的设置让TFS服务器能正常运行单元测试——因为TFS的测试环境可能是32位，或者单元测试框架对x64项目支持有限，Any CPU可以适配测试环境的架构，保证测试正常执行。

内容的提问来源于stack exchange，提问作者Andrew Stephens