我们有一个32位机器的初级开发人员.他仍然能够打开解决方案并在VS中运行吗？@H_502_3@
另外,一些项目引用第三方DLL.供应商提供32位和64位版本 – 哪些项目应该引用？如果我引用32位DLL,这将阻止应用程序作为64位应用程序运行？如果我参考64位版本,这是否会对32位开发人员造成问题？最终用户怎么样 – 我的安装程序需要检查操作系统版本并复制到相应的DLL中？@H_502_3@
最后,通过NuGet引用的DLL怎么样？ NuGet是否安装了32位或64位版本的DLL？如何处理32位或64位最终用户安装？@H_502_3@
解决方法
我们有一个32位机器的初级开发人员.他仍然能够打开解决方案并在VS中运行吗？@H_502_3@
是的,只要所有项目都设置为为任何cpu构建,并且在64位程序集或本机DLL上没有外部依赖关系.@H_502_3@
如果我引用32位DLL,这将阻止应用程序作为64位应用程序运行？@H_502_3@
是的,如果任何组件或链接的COM组件是专门针对32位CLR构建的,那么它将要求整个项目作为32位进程运行.您始终必须小心您的项目可能依赖的本机代码.@H_502_3@
如果我参考64位版本,这是否会对32位开发人员造成问题？@H_502_3@
是的,如果有64位程序集,32位开发人员将无法在其机器上运行该项目.@H_502_3@
作为最后的想法,我想补充说,最终的可执行项目是否构建为任何cpu,或者是特定的32位或64位目标平台是非常重要的.@H_502_3@
通常我发现,最终的可执行文件构建为任何cpu都可能会在运行时(Bad Image运行时异常类型)导致各种问题,除非链接的所有程序集都针对任何cpu,并且没有外部的本地依赖关系.后一种要求是最难确定的.@H_502_3@
另一方面,为明确指定的32位或64位平台构建的最终可执行文件可以高兴地并入为任何cpu构建的其他程序集@H_502_3@
