Перекрытие MSBuildExtensionsPath в задаче MSBuild является слоеным

Question

Это уже кросс-вывешено на MS Connect:

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

Я пытаюсь переопределить свойство $ (MSBuildExtensionsPath) при создании раствора, содержащий C# веб-приложение проект через msbuild. Я делаю это, потому что файл 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. Этот подход позволяет мне удалить зависимость, не требуя от меня вручную изменить файл csproj веб-приложения.

Эта схема отлично работает, когда я создаю файл решения из командной строки, поставляя пользовательское значение $ (MSBuildExtensionsPath) в командной строке для msbuild с помощью флага/p. Тем не менее, если я попытаюсь построить решение с помощью задачи MSBuild в файле проекта MSbuild (переопределяя MSBuildExtensionsPath с помощью атрибута «Свойства»), он терпит неудачу, потому что файл csproj веб-приложения пытается импортировать файлы Microsoft.WebApplication.targets из «стандартное» местоположение Microsoft.WebApplication.targets (C: \ Program Files \ MSBuild). Примечательно, что если я запустил msbuild, используя задачу «Exec» в моем пользовательском файле проекта, он работает. Еще более важно, В ПЕРВОЕ время, когда я запускаю сборку, используя задачу «MSBuild» ПОСЛЕ того, как я запустил сборку, используя задачу «EXEC» (или непосредственно из командной строки), сборка работает.

Кто-нибудь видел подобное поведение раньше? Я сумасшедший? Кто-нибудь знает о первопричине этой проблемы, о возможном обходном пути или о том, является ли это законной ошибкой в ​​MSBuild?

Шаги по воспроизведению:

1) Создайте новый пустой решение в МСВС 2008 (Fake.sln)

2) Добавить новый C# веб-приложение к решению (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) Создайте пользовательский файл проекта MSBuild с именем «TestBuild.proj» в том же каталоге, что и решение. Он должен иметь следующее содержание:

<?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) выполнить «MsBuild TestBuild.proj» из командной строки МСВС (примечание: сборка может добиться успеха в первый раз, но потерпит неудачу, если вы работаете больше, чем один раз)

Answer 1

Это ошибка в MSBuild 3.5, но исправлено в MSBuild 4.

Если вы можете, переключитесь на MSBuild 4 (вы все равно можете скомпилировать ваши проекты 3.5), иначе вам нужно будет override the property в файле проекта.

Answer 2

Он отлично работает, если вы переопределяете MSBuildExtensionsPath прямо в веб-приложении .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" /> 

Answer 3

Вы пытались установить переменную среды MSBuildExtensionPath в приглашении CMD, а затем запустить сборку?

Например:

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

Тогда на этом файле проекта:

вы получите следующий результат:

c: \ Users \ chuckeng \ Desktop \ ConsoleApplication1> "C: \ Windows \ Microsoft.NET \ Framework \ v3.5 \ MSBuild.exe". my.proj Версия для разработки Microsoft (R) версии 3.5.30729.4926 [Microsoft .NET Framework, версия 2.0. 50727.4927] Copyright (C) Microsoft Corporation 2007. Все права защищены.

Сборка началась 25.06.2010 1:04:05 PM. Проект «c: \ my.proj» на узле 0 (цели по умолчанию). MSBuildExtensionsPath = "C: \ My \ MSBuild \ Extensons" Готовый проект "c: \ my.proj" (цели по умолчанию).

Строительство выполнено успешно. 0 Предупреждение (ы) 0 Error (s)

Время, прошедшее с начала 00: 00: 00,03

Это работает с v4.0, а также. Хотя, поддержка в целом лучше в версии 4.0 для таких вещей. И, v4.0 на 100% обратная совместимость (ошибки не выдерживают). Таким образом, вы можете создавать свои v3.5 и предыдущие проекты с помощью v4.0. Просто выберите ToolsVersion 3.5. MSBuild my.proj /tv:3.5

Надеется, что это помогает ...

Chuck Англия Visual Studio Руководителя программы - MSBuild

Answer 4

Не знает, если это может помочь кто-то в будущем, но я смог использовать следующее в верхней части моего файла, и он работает так, как я ожидал бы в 32 и 64-битных средах сборки.

<PropertyGroup> 
    <MSBuildExtensionsPath Condition=" '$(MSBuildExtensionsPath64)' != '' ">$(MSBuildExtensionsPath64)</MSBuildExtensionsPath> 
</PropertyGroup> 
<Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>