为什么 64 位 MSBuild 加载 32 位扩展? [英] Why is the 64-bit MSBuild loading 32-bit extensions?

问题描述

我正在尝试在 64 位机器上使用 MSBuild (v4.0) 构建一个项目.出于某种原因，MSBuild 正在尝试加载 32 位扩展，我不知道为什么.为了演示问题，我已将问题缩小到最小集合.

使用以下 MSBuild 项目文件:

<目标名称="测试"><Message Text="bin path: $(MSBuildBinPath)"/><Message Text="extensions path: $(MSBuildExtensionsPath)"/><Message Text="extensions path (x86): $(MSBuildExtensionsPath32)"/><Message Text="extensions path (x64): $(MSBuildExtensionsPath64)"/></目标></项目>

我得到这个输出:

Microsoft (R) 构建引擎版本 4.0.30319.1[微软 .NET 框架，版本 4.0.30319.1]版权所有 (C) Microsoft Corporation 2007.保留所有权利.构建于 2010 年 8 月 27 日上午 9:56:35 开始.在节点 1(默认目标)上项目D:5	est.proj".测试:bin 路径:C:WindowsMicrosoft.NETFramework64v4.0.30319扩展路径:C:Program Files (x86)MSBuild扩展路径 (x86): C:Program Files (x86)MSBuild扩展路径 (x64):C:Program FilesMSBuild完成构建项目D:5	est.proj"(默认目标).构建成功.0 警告0 错误已用时间 00:00:00.03

MSBuild 显然知道 32 位和 64 位扩展路径，从二进制路径看来很明显我正在运行 64 位 MSBuild.exe，但出于某种原因，它认为应该从 加载扩展Program Files (x86) 而不是 Program Files.这给我带来了麻烦，因为我有一个需要加载的扩展，必须在 32 位/64 位进程中正确加载，并且它不会加载(MSBuild 正在尝试在 64 位进程中加载​​ 32 位版本).

为什么?

解决方案

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:5	est.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 FilesMSBuild
Done Building Project "D:5	est.proj" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.03

MSBuild 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 位扩展?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！