代码之家  ›  专栏  ›  技术社区  ›  Mark

为什么64位MSBuild要加载32位扩展?

  •  9
  • Mark  · 技术社区  · 15 年前

    使用以下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文件,但出于某种原因,它认为应该从 Program Files (x86) 而不是 Program Files . 这给我带来了麻烦,因为我有一个需要加载的扩展,必须在32位/64位进程中正确加载,而且它不会加载(MSBuild正在尝试在64位进程中加载32位版本)。

    1 回复  |  直到 15 年前
        1
  •  14
  •   Mark    15 年前

    filed a bug 在Microsoft Connect上,它被关闭为“按设计”,解释如下:

    你说得很对——这已经改变了,严格地说,现在是错的。然而,这是一个有意识的决定。更改的原因是,其他产品安装的许多扩展名(如.targets文件)仅安装在32位程序文件位置。他们没有预料到64位的情况,但通常在64位MSBuild中工作得很好。当用户运行64位MSBuild时(因为它是Team Build 2010的默认值,所以现在非常常见),MSBuildExtensionsPath在过去会像您所期望的那样解析为64位程序文件。但是,这意味着所有这些.targets文件都找不到了,生成失败。让所有这些产品修复它们的设置创作是不实际的,特别是因为它已经发送给客户了。因此,我们进行了更改,使msbuildexetnspath始终指向32位位置。几乎没有人真正想要64位位置,这些人可以更改为MSBuildExtensionsPath64。这确实是一个最不坏的选择。

    我接受证据,但不同意结论。我相信那些坏安装程序的作者应该让他们的扩展不能在64位机器上工作。