为什么? 解决方案 I 在 Microsoft Connect 上提交了一个错误，它被关闭为按设计"，解释如下:>你说得完全正确——这已经改变了，严格来说，现在是错误的.然而，这是一个有意识的决定.更改的原因是其他产品安装的很多扩展名(例如 .targets 文件)仅安装在 32 位程序文件位置.他们没有预料到 64 位方案，但通常可以在 64 位 MSBuild 中正常工作.当用户运行 64 位 MSBuild(现在很常见，因为它是 Team Build 2010 的默认设置)时，MSBuildExtensionsPath 过去会按照您的预期解析为 64 位程序文件.然而，这意味着不再找到所有那些 .targets 文件并且构建失败.让所有这些产品修复他们的设置创作是不切实际的，特别是因为它已经交付给客户.因此，我们进行了更改，使 MSBuildExetnsionsPath 始终指向 32 位位置.似乎几乎没有人真的想要 64 位位置，而这些人可以更改为 MSBuildExtensionsPath64.这真的是一个最不坏的选择的问题.我接受证据，但我不同意结论.我相信损坏安装程序的作者应该让他们的扩展在 64 位机器上不起作用.I'm attempting to build a project using MSBuild (v4.0) on a 64-bit machine. For some reason, MSBuild is attempting to load a 32-bit extension, and I cannot figure out why. I've reduced the problem to the smallest set in order to demonstrate the issue.Using the following MSBuild project file:<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0"> <Target Name="test"> <Message Text="bin path: $(MSBuildBinPath)" /> <Message Text="extensions path: $(MSBuildExtensionsPath)" /> <Message Text="extensions path (x86): $(MSBuildExtensionsPath32)" /> <Message Text="extensions path (x64): $(MSBuildExtensionsPath64)" /> </Target></Project>I get this output:Microsoft (R) Build Engine Version 4.0.30319.1[Microsoft .NET Framework, Version 4.0.30319.1]Copyright (C) Microsoft Corporation 2007. All rights reserved.Build started 8/27/2010 9:56:35 AM.Project "D:5est.proj" on node 1 (default targets).test: bin path: C:WindowsMicrosoft.NETFramework64v4.0.30319 extensions path: C:Program Files (x86)MSBuild extensions path (x86): C:Program Files (x86)MSBuild extensions path (x64): C:Program FilesMSBuildDone Building Project "D:5est.proj" (default targets).Build succeeded. 0 Warning(s) 0 Error(s)Time Elapsed 00:00:00.03MSBuild obviously knows about the 32bit and 64bit extensions path, and from the binary path it seems clear that I'm running the 64-bit MSBuild.exe, but for some reason it believes that extensions should be loaded from Program Files (x86) instead of Program Files. This is causing me trouble, as I have an extension that I need loaded, that MUST be loaded correctly in a 32bit/64bit process, and it will not load (MSBuild is attempting to load the 32bit version in a 64bit process).Why? 解决方案 I filed a bug on Microsoft Connect, and it was closed as "By Design", with this explanation: You're exactly right -- this has changed, and strictly speaking, it's wrong now. However, this was a conscious decision. The reason it was changed was that very many extensions (such as .targets files) installed by other products are only installed in the 32 bit program files location. They did not anticipate 64 bit scenarios, but generally would work just fine in 64 bit MSBuild. When a user runs 64 bit MSBuild, which is quite common now because it's the default for Team Build 2010, MSBuildExtensionsPath would have in the past resolved to the 64 bit Program Files as you expect. However this meant that all those .targets files were not longer found and the build failed. It was not practical to get all those products to fix their setup authoring, especially since it had already shipped to customers. So we made the change to make MSBuildExetnsionsPath always point to the 32 bit location. Almost nobody seems to really want the 64 bit location, and those people can change to MSBuildExtensionsPath64. It was really a question of the least bad option here.I accept the evidence, but I disagree with the conclusion. I believe that authors of broken installers deserve to have their extensions not work on 64-bit machines. 这篇关于为什么 64 位 MSBuild 加载 32 位扩展?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
