5

这已经在 MS Connect 上交叉发布：

https://connect.microsoft.com/VisualStudio/feedback/details/560451

在通过 msbuild 构建包含 C# Web 应用程序项目的解决方案时，我试图覆盖属性 $(MSBuildExtensionsPath)。我这样做是因为 Web 应用程序 csproj 文件导入文件“$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets”。此文件由 Visual Studio 安装到标准 $(MSBuildExtensionsPath) 位置 (C:\Program Files\MSBuild)。我想消除对安装在机器上的这个文件的依赖（我想让我的构建服务器尽可能“干净”）。为了做到这一点，我想将 Microsoft.WebApplication.targets 包含在我的项目的源代码控制中，然后覆盖 $(MSBuildExtensionsPath)，以便 csproj 导入这个包含的 Microsoft.WebApplication.targets 版本。

当我从命令行构建解决方案文件时，此方案工作正常，通过 /p 标志在命令行向 msbuild 提供 $(MSBuildExtensionsPath) 的自定义值。但是，如果我尝试使用自定义 msbuild 项目文件中的 MSBuild 任务构建解决方案（使用“Properties”属性覆盖 MSBuildExtensionsPath），则会失败，因为 Web 应用程序 csproj 文件正在尝试从“标准”Microsoft.WebApplication.targets 位置（C:\Program Files\MSBuild）。值得注意的是，如果我使用自定义项目文件中的“Exec”任务运行 msbuild，它就可以工作。更值得注意的是，在我使用“EXEC”任务（或直接从命令行）运行构建之后，我第一次使用“MSBuild”任务运行构建，构建工作正常。

有没有人见过这样的行为？我疯了吗？是否有人知道此问题的根本原因、可能的解决方法，或者这是否是 MSBuild 中的合法错误？

重现步骤：

1) 在 MSVS 2008 (Fake.sln) 中创建一个新的空解决方案

2) 将新的 C# Web 应用程序添加到解决方案 (WebApplication1.csproj)

3) 关闭 MSVS

4) 将“C:\Program Files\MSBuild\”的内容复制到包含您的解决方案的目录中名为“MSBuildExtensions”的目录中。

5) 重命名目录“C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications”，这样 WebApplication1.csproj 将无法从该位置导入 Microsoft.WebApplication.targets。

6) 在与解决方案相同的目录中创建一个名为“TestBuild.proj”的自定义 MSBuild 项目文件。它应具有以下内容：

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="BuildMSBuild">

<PropertyGroup>
    <MSBuildExtensionsPath>$(MSBuildProjectDirectory)\MSBuildExtensions\</MSBuildExtensionsPath>
    <BuildThis>Fake.sln</BuildThis>
</PropertyGroup>

<Target Name="BuildMSBuild">
    <MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);" Targets="Clean" />
    <MSBuild Projects="$(BuildThis)" Properties="MSBuildExtensionsPath=$(MSBuildExtensionsPath);"/>
</Target>

</Project>

7) 在 MSVS 命令提示符下执行“msbuild TestBuild.proj”（注意：第一次构建可能会成功，但如果多次运行则会失败）

4

4 回答 4

5

您是否尝试在 CMD 提示符中设置环境变量MSBuildExtensionPath然后运行您的构建？

例如：

C:\> SET MSBuildExtensionsPath=C:\My\MSBuild\Extensons

然后在这个项目文件上：

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Build">
    <Message Text='MSBuildExtensionsPath="$(MSBuildExtensionsPath)"' />
  </Target>
</Project>

您将获得以下输出：

c:\Users\chuckeng\Desktop\ConsoleApplication1>"C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe" my.proj
Microsoft (R) Build Engine Version 3.5.30729.4926
[Microsoft .NET Framework, Version 2.0.50727.4927]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 6/25/2010 1:04:05 PM.
Project "c:\my.proj" on node 0 (default targets).
  MSBuildExtensionsPath="C:\My\MSBuild\Extensons"
Done Building Project "c:\my.proj" (default targets).


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

Time Elapsed 00:00:00.03

这也适用于 v4.0。虽然，在 v4.0 中对此类事情的支持通常更好。而且，v4.0 是 100% 向后兼容的（无法承受错误）。因此，您可以使用 v4.0 构建您的 v3.5 和以前的项目。只需选择 ToolsVersion 3.5。

msbuild my.proj /tv:3.5

希望这可以帮助...

Chuck England Visual Studio 项目经理 - MSBuild

于 2010-06-25T20:10:06.417 回答
3

如果您MSBuildExtensionsPath直接在 Web 应用程序.csproj文件中覆盖，它工作正常。

<PropertyGroup>
  <MSBuildExtensionsPath>C:\Users\madgnome\Desktop\msbuild</MSBuildExtensionsPath>

  <!-- It works too with relative path -->
  <!--<MSBuildExtensionsPath>..\msbuild</MSBuildExtensionsPath>-->
</PropertyGroup>

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
于 2010-05-20T19:18:42.207 回答
3

这是 MSBuild 3.5 中的错误，但在 MSBuild 4 中已修复。

如果可以，请切换到 MSBuild 4（您仍然可以编译 3.5 项目），否则您将不得不覆盖项目文件中的属性。

于 2010-05-22T08:41:34.457 回答
1

不知道这将来是否会对任何人有所帮助，但我能够在文件顶部使用以下内容，并且它在 32 位和 64 位构建环境中都可以正常工作。

<PropertyGroup>
  <MSBuildExtensionsPath Condition=" '$(MSBuildExtensionsPath64)' != '' ">$(MSBuildExtensionsPath64)</MSBuildExtensionsPath>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>
于 2013-01-17T18:33:18.030 回答