Внешняя ошибка сборки VS2013 «ошибка MSB4019: импортированный проект <путь> не найден»


201

Я строю проект через командную строку, а не внутри 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. Я попытался искать в реестре, и это ничего не дало.

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

Мысли?


Подобный вопрос здесь stackoverflow.com/questions/17433904/…
Энтони Ф

В моем случае мне пришлось указать правильный VisualStudioVersion в событии сборки, которое создавалось с целью WebPublish.
user145400

Ответы:


250

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

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

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

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

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

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

msbuild myproject.csproj /p:VisualStudioVersion=12.0

или измените определение вашей сборки:

измените определение сборки, чтобы указать свойство <code> VisualStudioVersion </ code>


1
Я получил ошибку, используя msbuild из командной строки. Удаление этой части из файла проекта решило проблему.
Питер Хедберг

7
Я использовал этот ответ, и он работал, только если я убедился, что мой файл * proj начинался с <Project ToolsVersion = "12" До того, как у меня было <Project ToolsVersion = "4", и каждый раз, когда я открывал проект в VS, он снова добавлял два узла (т.е. он перенес проект на последнюю версию).
Сиелу

3
@giammin, я уже нашел решение. НЕ удаляйте раздел из вашего файла проекта. Установите правильную версию инструментов в своем определении сборки. Это очень легко сделать. Откройте определение сборки и перейдите на страницу «Процесс». Затем в группе «3. Дополнительно» у вас есть свойство под названием «Аргументы MSBuild». Поместите туда параметр со следующим синтаксисом "/p:VisualStudioVersion=12.0". Конечно без кавычек. Если у вас есть больше параметров, разделите их пробелом, а не запятой. Конфигурация, которую вы предложили удалить, используется другими частями Visual Studio в вашем процессе сборки ...
Ральф Янсен

9
Удаление этой строки, кажется, нарушает Web Deploy
Колин Пир

4
У меня та же проблема была решена с помощью свойства /p:VisualStudioVersion=12.0, как рекомендовано выше. Спасибо
Randeep

70

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

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

/p:VisualStudioVersion=12.0 

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


1
Мы только что завершили обновление с TFS 2005 до TFS 2013, и это было нашим последним препятствием. Это определенно сработало для нас и спасло меня от распутывания волос. Спасибо! +1.
Саймон Уайтхед

2
В этой статье Саида Ибрагима Хашими описывается проблема в Visual Studio 2010/2012. Сборка командной строки использует формат файла sln версия -1 в качестве VisualStudioVersion. Вы можете переопределить это значение из командной строки, как описывает Ральф, или как свойство задачи MSBuild из сценария сборки. У меня была та же проблема с Visual Studio 2013, и переопределение VisualStudioVersion решило проблему.
Макдон

1
Это сработало и для нас. Мы также рассмотрели возможность изменения самого шаблона сборки, описанного здесь , который может быть лучшим вариантом, если у вас есть десятки определений сборки.
JamesQMurphy,

это сработало для меня. Я удалил в файлах csproj любую ссылку на visualstudioversion, а затем добавил этот аргумент
msbuild

51

Это тесно связано, но может или не может исправить конкретную проблему ОП. В моем случае я пытался автоматизировать развертывание сайта 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

NEW, 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

Это исправило это для меня. Кроме того, аналогичный ответ на аналогичный вопрос здесь: stackoverflow.com/a/19826448/61569
Энтони Ф

22

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

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

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

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


Спасибо вам большое, это решить мою проблему при создании nodeJS не найдено! +1node-gypCpp default.props
Погриндис

21

Решение Джаммина частично неверно. Вы НЕ ДОЛЖНЫ удалять всю 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)' != ''" />

10

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

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

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

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


5
Это, вероятно, распространенный сценарий при запуске сервера сборки (такого как CruiseControl или TeamCity), когда служба работает под определенной учетной записью службы, которая может даже не иметь разрешений для интерактивного рабочего стола. Этот совет решил эту проблему для меня (VS 2013 установлен на чистой установке Server 2008 R2, с CruiseControl.NET)
Дэвид Кивини

Где я могу увидеть мой "VisualStudioVersion"?
WEFX

@WEFX просмотрите переменные окружения, выбрав Systemиз панели управления, затем выберите Advanced system settingsи, наконец, нажмитеEnvironment Variables
Скотт,

6

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


Это сработало для меня и было предпочтительнее, чем изменение файла проекта.
Шон

4

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

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

  • Из

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

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

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

msbuild /p:VisualStudioVersion=12.0


1
ToolsVersion не должна быть единственной переменной, чтобы исправить это сообщение об ошибке, потому что я видел проект с ToolsVersion, который не мог быть собран правильно.
Патрик Дежарден

2

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

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


2

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

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

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


2

У меня была похожая проблема. Все предлагаемые решения просто обойти эту проблему, но не решить источник ошибки. Решение @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

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


2

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

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

изменить на

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

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


2

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

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

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

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


2

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

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

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

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


Я использовал «C: \ Program Files (x86) \ Microsoft Visual Studio \ 2019 \ Enterprise \ MSBuild \ Current \ Bin \ MSBuild.exe» вместо «C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ MSBuild». exe "и это сработало
ELKALAKHI Мухаммед

Да, я использую проект SSDT (.sqlproj) с VisualStudioVersion = 14.0 в файле проекта. Я установил ядро ​​3.1, которое установило мои env vars для целей, чтобы Бог знал только где. Использование msbuild в папке, которую вы предложили, работает как шарм!
Мэтью Бек

1

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

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

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

Это сработало для меня.


1

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


Или скопируйте только файл Microsoft.WebApplication.targets из места, где установлена ​​Visual Studio 2013.
ThatBlairGuy

0

ты найдешь

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

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


0

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


0

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

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


0

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


0

На основе TFS 2015 Build Server

Если вы противостоите этой ошибке ... 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> -->


0

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


0

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


0

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

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

Это было найдено в:

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

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

C:\Program Files (x86)\MSBuild

Чтобы найти другие версии.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.