Ошибка внешней сборки VS2013 MSB4019: импортированный проект ‹path› не найден

Я создаю проект через командную строку, а не внутри Visual Studio 2013. Обратите внимание, я обновил свой проект с Visual Studio 2012 до 2013 года. Проект отлично строится внутри IDE. Кроме того, я сначала полностью удалил VS2012, перезагрузил и установил VS2013. Единственная имеющаяся у меня версия Visual Studio - 2013 Ultimate.

ValidateProjects:
    39>path_to_project.csproj(245,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 <Import> declaration is correct, and that the file exists on disk.
    39>Done Building Project "path_to_project.csproj" (Clean target(s)) -- FAILED.

Вот две строки, о которых идет речь:

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

Первоначальная вторая строка была v10.0, но я вручную изменил ее на v12.0.

$ (VSToolsPath) расширяется от того, что я вижу, до папки v11.0 (VS2012), которой, очевидно, больше нет. Путь должен был быть до v12.0.

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\

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

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

Мысли?


person Sarah Weinberger    schedule 31.10.2013    source источник
comment
Аналогичный вопрос здесь stackoverflow.com/questions/17433904/   -  person Anthony F    schedule 15.04.2015
comment
В моем случае мне пришлось указать правильную версию VisualStudioVersion в событии сборки, которое создавалось с целью WebPublish.   -  person user145400    schedule 06.02.2017


Ответы (24)


У меня была такая же проблема, и я нашел более простое решение

Это связано с тем, что Vs2012 добавляет в файл csproj следующее:

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Вы можете безопасно удалить эту часть, и ваше решение будет построено.

Как отметил Сиелу убедитесь, что файл .proj начинается с <Project ToolsVersion="12", иначе при следующем открытии проекта с помощью Visual Studio 2010 удаленный узел снова будет добавлен.

В противном случае, если вам нужно использовать webdeploy или вы используете сервер сборки, вышеуказанное решение не будет работать, но вы можете указать свойство VisualStudioVersion в своем скрипте сборки:

msbuild myproject.csproj /p:VisualStudioVersion=12.0

или отредактируйте определение сборки:

отредактируйте определение сборки, чтобы указать свойство ‹code› VisualStudioVersion ‹/code›»></p>
                        <div class= person giammin    schedule 20.11.2013

comment
Я получил ошибку, используя msbuild из командной строки. Удаление этой части из файла проекта решило проблему. - person Peter Hedberg; 14.01.2014
comment
Я использовал VS2013 с TFS2012, и это решение сработало для меня. - person John Mills; 22.01.2014
comment
Я использовал этот ответ, и он сработал только в том случае, если я убедился, что мой файл * proj начинается с ‹Project ToolsVersion = 12 До того, как у меня был‹ Project ToolsVersion = 4, и каждый раз, когда я открывал проект в VS, он снова добавлял два узла (т.е. -переведен проект до последней версии). - person Sielu; 04.03.2014
comment
Когда я это сделал, мои файлы wpp.targets в моем решении больше не работали. У меня эта проблема возникает только тогда, когда я устанавливаю только VS2013 на компьютер, а не на сервер, а затем использую его как машину для сборки. На моем собственном компьютере установлена ​​чистая установка, я установил только VS2010 и VS2013, и с этой частью конфигурации все работает нормально. Даже если вы выберете новый проект в VS2013 и посмотрите на созданный файл проекта, часть конфигурации также будет там. Значит, должно быть что-то еще ... - person LockTar; 21.03.2014
comment
@RalphJansen да это если у вас только vs2013 - person giammin; 21.03.2014
comment
@giammin, я уже нашел решение. НЕ удаляйте раздел из файла проекта. Задайте правильную версию инструментов в определении сборки. Сделать это очень просто. Откройте определение сборки и перейдите на страницу «Процесс». Затем в группе 3. Advanced у вас есть свойство под названием MSBuild Arguments. Поместите туда параметр со следующим синтаксисом /p:VisualStudioVersion=12.0. Конечно без кавычек. Если у вас есть другие параметры, разделите их пробелом, а не запятой. Конфигурация, которую вы предложили удалить, используется другими частями Visual Studio в процессе сборки ... - person LockTar; 21.03.2014
comment
@RalphJansen, это решение работает для вас, потому что у вас есть vs2010 - person giammin; 21.03.2014
comment
Это сработало для меня и снова заставило меня построить только VS2013. - person Neil; 17.07.2014
comment
Удаление этой строки, похоже, нарушает веб-развертывание - person Colin Pear; 14.08.2014
comment
У меня такая же проблема была решена с помощью свойства /p:VisualStudioVersion=12.0, как рекомендовано выше. Спасибо - person Randeep; 02.03.2015
comment
Проголосовать за /p:VisualStudioVersion=12.0, это решило мою проблему в интеграции с Jenkins - person Elaine; 13.05.2016

У меня тоже было это, и вы можете исправить это, указав версию инструментов в определении сборки.

Сделать это очень просто. Откройте определение сборки и перейдите на страницу «Процесс». Затем в группе «3. Дополнительно» у вас есть свойство под названием «Аргументы MSBuild». Поместите туда параметр со следующим синтаксисом

/p:VisualStudioVersion=12.0 

Если у вас есть другие параметры, разделите их пробелом, а не запятой.

person LockTar    schedule 21.03.2014
comment
Мы только что завершили обновление с TFS 2005 до TFS 2013, и это было нашим последним препятствием. Это определенно сработало для нас и спасло меня от выдергивания волос. Огромное спасибо! +1. - person Simon Whitehead; 14.08.2014
comment
Эта статья Сайеда Ибрагима Хашими описывает проблему в Visual Studio 2010/2012. При сборке из командной строки в качестве VisualStudioVersion используется формат файла sln версии -1. Вы можете переопределить это значение из командной строки, как описывает Ральф, или как свойство задачи MSBuild из сценария сборки. У меня была такая же проблема с Visual Studio 2013, и переопределение VisualStudioVersion решило проблему. - person mcdon; 19.08.2014
comment
Это сработало и для нас. Мы также рассмотрели возможность изменения самого шаблона сборки, описанного здесь, что может быть лучшим вариантом, если у вас есть десятки определений сборки. - person JamesQMurphy; 20.09.2014
comment
это сработало для меня. Я удалил в файлах csproj любую ссылку на visualstudioversion, а затем добавил этот аргумент msbuild - person Jhayes2118; 09.10.2014

Это тесно связано, но может или не может исправить конкретную проблему OP. В моем случае я пытался автоматизировать развертывание сайта Azure с помощью VS2013. Сборка и развертывание через VS работает, однако использование MSBuild показало аналогичную ошибку в отношении «целей». Оказывается, MSBuild отличается от VS2013 и теперь является частью VS, а не .NET Framework (см. http://timrayburn.net/blog/visual-studio-2013-and-msbuild/). Как правило, используйте правильную версию MSBuild:

СТАРЫЙ, VS2012

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

НОВИНКА, VS2013

C:\Program Files (x86)\MSBuild\12.0\bin\msbuild.exe

Новее, VS2015

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Еще новее, VS2017 (не полностью тестируется, но обнаружен - они немного переместили)

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\msbuild.exe
person Jester    schedule 18.10.2014
comment
Это исправило это для меня. Кроме того, аналогичный ответ на аналогичный вопрос здесь: stackoverflow.com/a/19826448/61569 - person Anthony F; 15.04.2015

Я только что получил ответ от Kinook, который дал мне ссылку:

В принципе, мне нужно позвонить по следующему адресу перед постройкой. Я предполагаю, что Visual Studio 2013 не регистрирует среду автоматически, но 2012 год сделал, или я это сделал и забыл.

call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86

Надеюсь, этот пост поможет кому-то другому.

person Sarah Weinberger    schedule 31.10.2013
comment
Большое спасибо, это решило мою проблему, когда сборка nodeJS node-gyp Cpp default.props не была найдена! +1 - person Pogrindis; 05.10.2016

Решение giammin частично неверно. Вам НЕ СЛЕДУЕТ удалять всю эту группу PropertyGroup из решения. Если да, Функция MSBuild "DeployTarget = Package" перестанет работать. Эта функция зависит от установленного "VSToolsPath".

<PropertyGroup>
  <!-- VisualStudioVersion is incompatible with later versions of Visual Studio.  Removing. -->
  <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> -->
  <!-- VSToolsPath is required by MSBuild for features like "DeployTarget=Package" -->
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
...
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
person cat5dev    schedule 03.06.2014

У меня была эта проблема для наших целей FSharp (FSharpTargetsPath был пуст).

Многие пути построены со ссылкой на версию VS.

По разным причинам наша сборка выполняется с системными привилегиями, а переменная среды «VisualStudioVersion» была установлена ​​(установщиком VS 2013) только на «пользовательском» уровне, что вполне справедливо.

Убедитесь, что для переменной среды «VisualStudioVersion» установлено значение «12.0» на уровне (системном или пользовательском), на котором вы работаете.

person Scott    schedule 29.01.2014
comment
Вероятно, это распространенный сценарий при запуске сервера сборки (например, CruiseControl или TeamCity), где служба работает под определенной учетной записью службы, которая может даже не иметь разрешений для интерактивного рабочего стола. Этот совет решил проблему для меня (VS 2013 установлен на чистой установке Server 2008 R2 с CruiseControl.NET) - person David Keaveny; 20.02.2014
comment
Где я могу увидеть свою версию VisualStudioVersion? - person WEFX; 15.06.2018
comment
@WEFX просмотрите переменные среды, выбрав System на панели управления, затем выберите Advanced system settings и, наконец, щелкните Environment Variables - person Scott; 16.06.2018

Запуск этого в командной строке также решит проблему. SETX VisualStudioVersion "12.0"

person Steve    schedule 22.01.2014
comment
Это сработало для меня и было предпочтительнее, чем изменение файла проекта. - person Sean; 04.07.2014

Если вы переносите Visual Studio 2012 на 2013, откройте файл проекта * .csprorj с помощью edior.
и проверьте элемент ToolsVersion тега Project.

Это значение 4,0
Вы доведете до 12,0

  • # P3 #
    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="4.0"
    
  • To

    <?xml version="1.0" encoding="utf-8"?>
    <Project ToolsVersion="12.0"
    

Или, если вы строите с помощью msbuild, просто укажите свойство VisualStudioVersion

msbuild /p:VisualStudioVersion=12.0

person Kim Ki Won    schedule 28.05.2014
comment
ToolsVersion не должна быть единственной переменной для исправления этого сообщения об ошибке, потому что я видел проект с ToolsVersion, который не мог правильно построить. - person Patrick Desjardins; 14.07.2014

Я использовал внешнюю утилиту для сборки. Подумайте о чем-то вроде Муравьев, если я правильно понимаю продукт, просто коммерческую версию. Пришлось связаться с производителем для ответа.

Как оказалось, в проекте есть глобальный макрос DEVSTUDIO_NET_DIR. Мне пришлось изменить там путь к .Net. Они перечисляют различные версии визуальной студии как «Действия», которые через меня отключены, но все дороги ведут к этой единственной скрытой глобальной переменной. Я бы перечислил это как дефект продукта, если бы у меня был свой путь, если я не упустил что-то в своем понимании. Исправление пути там устранило проблему сборки.

person Sarah Weinberger    schedule 20.11.2013

У меня установлена ​​Visual Studio 2013. Это сработало для меня:

<PropertyGroup>
    <VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
    <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>

Итак, я изменил условие с == на != и значение с 10.0 на 12.0.

person pinus.acer    schedule 10.07.2014

У меня была аналогичная проблема. Все предлагаемые решения просто обходят эту проблему, но не устраняют источник ошибки. Решение @giammin не следует применять, если вы используете сервер сборки tfs, поскольку это просто сбой функции публикации. Решение @ cat5dev - решает проблему, но не устраняет ее источник.

Я почти уверен, что вы используете шаблон процесса сборки для VS2012, например ReleaseDefaultTemplate.11.1.xaml or DefaultTemplate.11.1.xaml эти шаблоны сборки были созданы для VS2012, а для $ (VisualStudioVersion) установлено значение 11.0

Вы должны использовать шаблон процесса сборки для VS2013 ReleaseTfvcTemplate.12.xaml or TfvcTemplate.12.xaml, для которого $ (VisualStudioVersion) установлено значение 12.0

Это работает без каких-либо изменений в файле проекта.

person Imaginary    schedule 05.09.2014

У меня тоже была такая же ошибка .. Я сделал это, чтобы исправить

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" />

изменить на

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

и дело сделано.

person Pyro    schedule 17.05.2016

В моем случае я просто прокомментирую строку ниже, открыв файл .csproj и сделаю трюк

.<!-- <Import Project="..\PRPJECTNAME.targets" /> -->

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

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

person Usman Younas    schedule 30.03.2017

Используйте правильную версию MSBuild. Установите для переменной среды значение:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin

Это также будет работать для проектов VS 2019

Раньше мы устанавливали C:\Windows\Microsoft.NET\Framework\v4.0.30319

person Manish    schedule 04.12.2019
comment
Я использовал C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe вместо C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild.exe и его работал - person ELKALAKHI Mohammed; 27.12.2019
comment
Да, я использую проект SSDT (.sqlproj) с VisualStudioVersion = 14.0 в файле проекта. Я установил ядро ​​3.1, которое установило мои env vars для целей Бог знает где. Использование msbuild в предложенной вами папке сработало отлично! - person Matthew Beck; 27.01.2020

В моем случае среда разработки - VS2013, и я использую TFS 2010. Сборка была нацелена на .NET 4.5.1. Я настраивал автоматическую сборку для CI. всякий раз, когда я пробовал обходные пути, упомянутые выше, например, полное удаление группы свойств или замену некоторых строк и т. д., моя сборка выполнялась в TFS, но моя публикация в Azure использовалась с ошибкой `` MSDeploy '' или иногда с другой ошибкой. Я не смог достичь того и другого одновременно.

Итак, наконец, мне пришлось передать аргумент MSBuild, чтобы решить проблему.

Перейти к Редактировать определение сборки> Процесс> 3. Дополнительно> Аргументы MSBuild (установлено) /p:VisualStudioVersion=12.0

У меня это сработало.

person Vishwajit G    schedule 18.09.2014

Вы должны скопировать папку WebApplications из C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v12.0 \ в C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \

person Tazos333    schedule 03.10.2014
comment
Или скопируйте только файл Microsoft.WebApplication.targets из места, где установлена ​​Visual Studio 2013. - person ThatBlairGuy; 08.01.2016

ты найдешь

C:\Program Files  (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets 

в файле csproj, для которого появляется эта ошибка. Просто удалите это из csproj, а затем соберите.

person Mukund    schedule 14.02.2014

Для решения проблемы необходимо только одно: обновить TeamCity до версии 8.1.x или выше, поскольку поддержка Visual Studio 2012/2013 и MSBuild Tools 2013 была представлена ​​только в TeamCity 8.1. После обновления TeamCity измените параметр версии MSBuild Tools Version на этапе сборки, и проблема исчезнет. Подробнее читайте здесь: http://blog.turlov.com/2014/07/upgrade-teamcity-to-enable-support-for.html

person Alex T.    schedule 24.07.2014

Я - ничто не помогло в изменении значения v11.0 переменной VisualStudioVersion на v10.0. Изменение переменной в файле .csproj не произошло. Установка его через командную строку - нет. Так далее...

Закончилось копирование моей локальной папки этой конкретной версии (v11.0) на мой сервер сборки.

person Jurijs Kastanovs    schedule 21.08.2014

Я пробовал все вышеперечисленные решения, но все равно не повезло. Я слышал, как люди устанавливают Visual Studio на свои серверы сборки, чтобы исправить это, но у меня было только 5 ГБ свободного места, поэтому я просто скопировал C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio на свой сервер сборки и назвал это днем . После этого начал работать, используя team city 9.x и visual studio 2013.

person odyth    schedule 04.02.2016

На основе сервера сборки TFS 2015

Если вы противодействуете этой ошибке ... Error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

Откройте .csproj файл проекта, указанного в сообщении об ошибке, и закомментируйте раздел ниже.

<!-- <PropertyGroup> --> <!-- <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion> --> <!-- <VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath> --> <!-- </PropertyGroup> -->

person Julius Depulla    schedule 10.03.2017

Я получил эту ошибку при установке некоторых компонентов VS. К сожалению, ни один из этих ответов мне не помог. Я использую TFS для разработки команд, и у меня нет прав на редактирование определения сборки. Я решил эту проблему, удалив переменные среды с именами VS110COMNTOOLS и VS120COMNTOOLS. Я думаю, что он был установлен с моими компонентами VS.

person Joseph Katzman    schedule 27.03.2017

Я обнаружил, что мне не хватает папки WebApplications на моем локальном ПК, я не установил Visual Studio 2017, как это было, когда я использовал 2012.

person Kris    schedule 28.07.2017

В моем случае я использовал неправильную версию MSBuild.exe.

Версия, которую вам нужно использовать, зависит от того, какую версию Visual Studio вы использовали для создания своего проекта. В моем случае мне понадобилось 14.0 (при использовании Visual Studio 2015).

Это было найдено по адресу:

C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe

Вы можете посмотреть:

C:\Program Files (x86)\MSBuild

Найти другие версии.

person EM-Creations    schedule 03.10.2018