v11.0 \ WebApplications \ Microsoft.WebApplication.targets не был найден, когда файл действительно ссылается на v10

84

Сначала немного предыстории. В конце 2012 года мы перенесли наше решение vs2008 на vs2010, но по-прежнему ориентируемся на .NET 3.5. (Я знаю здесь только самое последнее и лучшее!)

У нас не было никаких проблем с этой настройкой до тех пор, пока несколько недель назад люди не начали получать следующие ошибки:

"foo.csproj" (Rebuild target) (16:5) ->
  C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.

Интересно то, что если вы посмотрите на файл проекта, он ссылается на v10, что имеет смысл, потому что мы не используем Visual Studio 2012.

Эта ошибка поразила сразу нескольких из нас, и даже в старых ветках кода, которые не менялись месяцами.

Я подозреваю, что на наши машины было загружено какое-то обновление, которое запутало ситуацию, но я не знаю, что с этим делать.

Кратковременным решением было установить VS 2012 и не использовать его, но я надеюсь на что-то более чистое, чем это.

asp.net  .net  visual-studio-2010  visual-studio-2008  visual-studio-2012 
— drs9222
источник
17
Я обнаружил, что добавление "/p:VisualStudioVersion=10.0" в командную строку MSBuild устраняет эту проблему, но это все равно похоже на взлом.
— drs9222 05

Ответы:

116

Я столкнулся с той же проблемой с Visual Studio 2013. Оказалось, что я использовал старую версию MSBuild - ту, которая поставляется с .NET Framework - из командной строки. Microsoft теперь выпускает MSBuild как часть самой Visual Studio, а также как отдельный установщик ( http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of- visual-studio.aspx ).

Решением было использовать новую версию MSBuild.exe, расположенную в C:\Program Files (x86)\MSBuild\12.0\Bin. Как только я это сделал, все ошибки цели исчезли.

ИЗМЕНИТЬ 1

Как упоминалось в комментариях, каждая новая версия MSBuild приносит с собой новый каталог. Для Visual Studio 2015 используйте C:\Program Files (x86)\MSBuild\14.0\Bin.

ИЗМЕНИТЬ 2

Как упоминалось в комментариях, для Visual Studio 2017 используйте C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.

— НатанАлден-старший
источник
1
Я разместил запрос на форуме TeamCity, чтобы включить новый путь (а-ля, как обрабатываются настройки NuGet). Надеюсь, они быстро с этим справятся.
— Дэвид Педен
1
Прямая ссылка в сообщении блога на загрузку отдельных инструментов больше не действует. Правильная ссылка: microsoft.com/en-us/download/details.aspx?id=40760 .
— Дэвид Педен
1
И вот тут на помощь приходит Jetbrains с версией 8.0.5. Официальная запись в блоге: teamcitydev.blogspot.com/2013/11/…
— Дэвид Педен
1
Если у вас есть локальные сценарии сборки Powershell, вы можете просто добавить в свой путь: $env:Path = $env:Path + ";C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications"и использовать v4 msbuild (вы также можете сделать это в своем сборочном блоке)
— Крис С.
4
Да! Спасибо - это правильное решение.
— Джош М.
53

Если у вас есть сервер сборки, на котором не установлен VS2012, вы можете исправить это с помощью

а) установка пакета MSBuild.Microsoft.VisualStudio.Web.targets в ваше решение и

б) заменив эту строку в файле .csproj:

<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Эта строка указывает на пакет nuget

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />

РЕДАКТИРОВАТЬ

Как @joedragons баллы из версии в обновленной линии должны соответствовать NuGet версии пакета, то есть заменить targets.11.0.2.1с targets.x.x.x.xтекущей версией.

— Даниэль де Цваан
источник
1
Так же отличный совет!
— Кевин Оби,
2
Спасибо, отличное решение
— Павел
1
Возможно, это очевидно, но строка, которую вы заменяете, должна содержать версию устанавливаемого пакета. Я установил 12.0.4, поэтому при замене импорта я получил ту же ошибку. Когда я перешел на ... Web.targets.12.0.4 \ ... все хорошо =) Большое спасибо!
— joedragons
2
Вам больше не нужна часть b этого ответа. По какой-то причине SO отклонил мое редактирование, чтобы удалить ненужные детали.
— bbodenmiller 06
1
спасибо, я сделал то же самое с последней версией MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3
— Ахмед Самир
23

Простое решение этой проблемы:

Идите по следующему пути:

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio

Вы увидите последнюю версию V10.0, v11.0, v12.0 в зависимости от установленной вами Visual Studio 2010, 2012 или 2013.

Скопируйте WebApplicationsпапку из любого каталога последней версии и вставьте в другой.

Ваши проблемы должны быть решены.

— Самдубей
источник
1
Этот IMO - лучшее и простое решение :)
— gideon
Конечно, для этого требуется, чтобы у вас действительно был доступ для этого на сервере сборки.
— Дэйв
1
... но почему это нужно делать вручную? Спасибо .. это исправило это для меня в VS21017 (для меня это была свежая установка только с VS2017 - теперь я думаю, что это было потому, что я еще не установил IIS)
— Петр Кула
Работает также при копировании на V14.0.
— Uwe Keim
8

Вау. Мы только что видели то же самое на нашей машине сборки. Мы используем VS2010 и нацелен на .NET 4.0. Наши файлы проекта явно импортируют версию v10.0 этих целей. Без изменений в коде, вчера сборка прошла нормально, а сегодня не работает с жалобой на отсутствующую версию v11.0. .NET Framework 4.5.1 был установлен / обновлен прошлой ночью на этом компьютере сборки в качестве автоматического обновления. Мы собираемся форсировать версию 10.0 с параметром (или переменной env.), Но это определенно застало нас врасплох ...

ОБНОВЛЕНИЕ: что еще более странно, так это то, что похоже, что сегодняшняя версия msbuild использует первую строку файла sln, чтобы определить, какую VisualStudioVersion использовать по умолчанию, тогда как вчерашняя версия не использовала: 

Format Version 12.00

Мы протестировали вручную, изменив это значение на 11.00, и сборка снова заработала.

В нашем случае, хотя мы нацелены и строим все для 2010 / 4.0, некоторые разработчики готовились к VS2012 (поскольку MS утверждала, что файлы проекта совместимы), и это конкретное решение было в последний раз сохранено (несколько месяцев назад) в VS2012. До сегодняшнего дня это не было проблемой.

— lesscode
источник
1
Это помогло мне гораздо больше, чем ответ, получивший наибольшее количество голосов, который, похоже, касается совершенно другой ситуации.
— LambdaCruiser
То же самое здесь @LambdaCruiser, этот ответ очень помог. Я посмотрел на историю моего файла .sln, и, хотя вторая строка прочитала, # Visual Studio 2010первая строка закончилась тем, Format Version 12.00что на каком-то этапе я обновился до vs2012, но переключился туда и обратно на vs2010. Как и у Уэйна, эта проблема возникла после запуска обновления Windows на сервере CI
— wal
6

Я была такая же проблема. Исправлено с помощью перечисленных выше решений. Проблема вызвана тем, что соответствующая версия Visual Studio Tools (BuildTools) недоступна на сервере сборки. Как правильно указано выше, это можно решить, установив BuildTools, но в моем случае это не вариант.

Вот еще одна альтернатива - используйте Nuget 

Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3

Определите запускаемый проект и установите web.targets в зависимости от используемой версии Visual Studio. Следующие файлы будут изменены, включая необходимые изменения

В packages.config:

<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />

В .csproj:

<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />

Надеюсь это поможет!!! Удачи,

Привет,

— user2964808
источник
1
Идеальный ответ - устраняет необходимость обезьянничать с файлом csproj или копировать что-то на сервере сборки. Работал с несколькими версиями Visual Studio и MSBuild 2017. Я удалил строку «WebApplication.targets» вручную - nuget не удалял ее автоматически.
— Гедас Кутка
3

Взломал, но решил это путем копирования: c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ WebApplications *. * В c: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ WebApplications *. *

— Волк5
источник
1

Я получил эту ошибку в конце ноября, не внося никаких изменений ни в конфигурацию моей установки TeamCity, ни в установку MSBuild, ни в исходный код. На моем сервере сборки Visual Studio даже не установлена, а переход с VS2010 на VS2012 был произведен в конце августа без каких-либо проблем в то время.

Моя версия MSBuild - 4.0.30319.18408, мой сервер сборки - это Windows Server 2008 R2 SP1 с TeamCity v6.5.3.

Я решил проблему, просто скопировав папку v11 с другого сервера сборки, который не пострадал.

Я предполагаю, что это могло произойти двумя способами:

  1. Что-то обновилось, что привело к удалению папки v11. Может быть, обновление Windows до .NET или что-то в этом роде?

  2. Что-то было обновлено, что изменило мою конфигурацию TeamCity / MSBuild с использования v10 на v11, и сборки перестали работать, поскольку v11 никогда не существовало.

3 декабря у меня вышло обновление .NET Framework 4.5.1, может это быть причиной?

Brgds

Йонас

— Йонас
источник
0

Я недавно столкнулся с той же проблемой. И я пришел к выводу, что каждая версия VS (v10, v11, v12) меняет путь к переменной сборки, например MSBuildBinPath.

Таким образом, указание точной версии VS не является взломом, потому что у вас может даже не быть установленной соответствующей версии файлов. Так что лучше указать параметр и использовать цели, существующие на вашем компьютере.

В некоторых редких случаях вам может потребоваться установить определенную версию пакета VS и Web Deploy. В моем случае для решения проблемы было достаточно одной версии.

— Johnny_D
источник
0

Вы можете добавить свойство VisualStudioVersion следующим образом:

<ItemGroup>
  <ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
    <Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
  </ProjectToBuild>
</ItemGroup>
<MSBuild Projects="@(ProjectToBuild)" Targets="Rebuild"/>
— пользователь3586919
источник
0

Пока я искал, как решить эту проблему, почти все рекомендовали либо скопировать отсутствующую папку MSBUILD, либо установить какой-нибудь SDK какой-либо версии.

К счастью, я нашел очень полезный пост Донована Брауна: http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!

Вкратце, идея состоит в том, чтобы настроить версию VisualStudio, которую ваша сборка должна использовать в своем определении сборки:

Щелкните правой кнопкой мыши -> «Изменить определение сборки ...»

Перейдите в «Procss» -> «3. Advanced»

и установите "Аргументы MSBuild" с помощью 

/p:VisualStudioVersion=12.0
— А. Йосупов
источник
Не удается найти «Изменить определение сборки ...» в VS2019
— Laser42
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.