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

我正在尝试在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>

MSBuild显然知道32位和64位扩展名路径，从二进制路径看，我运行的是64位MSBuild.exe，但出于某种原因，它认为扩展名应该从

程序文件（x86）

加载，而不是从

程序文件

加载。这给我带来了麻烦，因为我有一个需要加载的扩展，必须在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位机器上工作

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