Question

我正在尝试在64位计算机上使用MSBuild（v4.0）构建项目。出于某种原因，MSBuild正在尝试加载32位扩展，我无法弄清楚原因。为了证明这个问题，我已将问题缩小到最小集。

使用以下MSBuild项目文件：

<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>

我得到了这个输出：

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\test.proj" on node 1 (default targets).
test:
  bin path: C:\Windows\Microsoft.NET\Framework64\v4.0.30319
  extensions path: C:\Program Files (x86)\MSBuild
  extensions path (x86): C:\Program Files (x86)\MSBuild
  extensions path (x64): C:\Program Files\MSBuild
Done Building Project "D:\5\test.proj" (default targets).


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

Time Elapsed 00:00:00.03

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

为什么？

Answer 1

我在Microsoft Connect上filed a bug，它被关闭为“按设计”，并附有以下解释：

你说得对 - 这已经改变了，严格来说，现在是错的。然而，这是一个有意识的决定。它被更改的原因是其他产品安装的很多扩展（例如.targets文件）仅安装在32位程序文件位置。他们没有预料到64位场景，但通常可以在64位MSBuild中正常工作。当用户运行64位MSBuild时，这是非常常见的，因为它是Team Build 2010的默认值，MSBuildExtensionsPath过去会按照您的预期解析为64位程序文件。但是，这意味着找不到所有那些.targets文件，并且构建失败。让所有这些产品修复他们的设置创作是不切实际的，特别是因为它已经发送给客户。因此我们进行了更改以使MSBuildExetnsionsPath始终指向32位位置。几乎没有人真的想要64位的位置，那些人可以改为MSBuildExtensionsPath64。这真的是一个最糟糕的选择问题。

我接受了证据，但我不同意这个结论。我相信破坏安装程序的作者应该让他们的扩展不能在64位计算机上运行。

为什么64位MSBuild加载32位扩展？

1 个答案: