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

标签 msbuild 64-bit 32-bit 32bit-64bit

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

为什么?

最佳答案

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

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.



我接受证据​​,但不同意结论。我认为,安装失败的作者应该拥有在64位计算机上无法使用其扩展程序的作者。

关于msbuild - 为什么64位MSBuild加载32位扩展?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3586040/

相关文章:

asp.net-mvc - 如何在发布期间使用 x64 aspnet_compiler

c# - 在 C# 中工作的正则表达式在 MSBuild 中不起作用

visual-studio-2010 - 在解决方案文件上调用 TransformWebConfig

android - RenderScript 和 PlayStore 64 位要求

c# - 不是有效的 Win32 应用程序

C++ 将 Int 拆分为 4 个部分(32 位机)

c - 应该与 32 位和 64 位进程一起工作的 64 位库

msbuild - 自定义通用目标来构建解决方案

visual-studio-2010 - 32/64 位的 MSBuild 和 $(ProgramFiles) 问题

gcc - x86_64 中运行时代码替换的绝对寻址