Внешняя ошибка сборки VS2013 "ошибка MSB4019: импортированный проект <путь> не найден"
Я строю проект через командную строку, а не внутри 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. Я попытался искать в реестре, и это ничего не дало.
К сожалению, я не вижу простого способа получить точную командную строку. Я использую инструмент сборки.
Мысли?
23 ответа
У меня была такая же проблема и я нашел более простое решение
Это связано с добавлением 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
или измените определение вашей сборки:
VisualStudioVersion
У меня было это тоже, и вы можете это исправить, установив версию инструментов в своем определении сборки.
Это очень легко сделать. Откройте определение сборки и перейдите на страницу "Процесс". Затем в группе "3. Дополнительно" у вас есть свойство под названием "Аргументы MSBuild". Поместите параметр туда со следующим синтаксисом
/p:VisualStudioVersion=12.0
Если у вас есть больше параметров, разделите их пробелом, а не запятой.
Это тесно связано, но может или не может исправить конкретную проблему ОП. В моем случае я пытался автоматизировать развертывание сайта 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
Я только что получил ответ от Kinook, который дал мне ссылку:
По сути, мне нужно позвонить по следующему номеру до начала строительства. Я предполагаю, что Visual Studio 2013 сначала не регистрирует среду автоматически, но 2012 сделал, или я сделал и забыл.
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" x86
Надеюсь, этот пост поможет кому-то еще.
Решение Джаммина частично неверно. Вы НЕ ДОЛЖНЫ удалять всю группу 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)' != ''" />
У меня была эта проблема для наших целей FSharp (FSharpTargetsPath был пуст).
Многие пути построены со ссылкой на версию VS.
По разным причинам наша сборка выполняется с системными привилегиями, а переменная окружения "VisualStudioVersion" была установлена (установщиком VS 2013) только на уровне "пользователя", что достаточно справедливо.
Убедитесь, что "VisualStudioVersion"переменная окружения установлена в"12.0"на уровне (Система или Пользователь), на котором вы работаете.
Выполнение этого в командной строке также решит проблему. SETX VisualStudioVersion "12.0"
Если вы перенастроили 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
Используйте правильную версию MSBuild. Задайте для переменной среды значение:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin
Это также будет работать для проектов VS 2019
Раньше мы устанавливали его на C:\Windows\Microsoft.NET\Framework\v4.0.30319
У меня тоже была такая же ошибка.. Я сделал это чтобы исправить
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" />
изменить на
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
и это сделано.
У меня установлена Visual Studio 2013. Это сработало для меня:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' != ''">12.0</VisualStudioVersion>`
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
Итак, я изменил условие с == в != и значение от 10.0 в 12.0,
Я использовал внешнюю утилиту сборки. Подумайте о чем-то вроде муравьев, если я правильно понимаю продукт, просто о коммерческой версии. Мне пришлось связаться с производителем для ответа.
Оказывается, в проекте есть глобальный макрос DEVSTUDIO_NET_DIR. Я должен был изменить путь к.Net там. Они перечисляют различные визуальные студийные версии как "Действия", которые меня выключают, но все дороги ведут к этой единственной глобальной переменной за кулисами. Я бы назвал это дефектом продукта, если бы у меня был свой путь, если я что-то не понял в моем понимании. Исправление пути там решило проблему сборки.
В моем случае я просто прокомментировал строку ниже, открыв файл.csproj, и сделал свое дело
,<!-- <Import Project="..\PRPJECTNAME.targets" /> -->
Моя проблема может быть другой, но меня притащили сюда, но это может кому-то помочь.
Я выбрал один веб-проект из своего решения и попытался открыть его как отдельный проект, который создавал проблему, после того, как я смог решить проблему.
У меня была похожая проблема. Все предлагаемые решения просто обойти эту проблему, но не решить источник ошибки. Решение @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
Это работает без каких-либо изменений в файле проекта.
Вы должны скопировать папку WebApplications из C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\ в C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\
В моем случае среда разработки VS2013, и я использую TFS 2010. Сборка была предназначена для.NET 4.5.1. Я настраивал автоматическую сборку для CI. всякий раз, когда я пробовал обходные пути, упомянутые выше, такие как полное удаление группы свойств или замена некоторых строк и т. д. моя сборка происходила в TFS, но моя публикация в azure обычно заканчивалась ошибкой с "MSDeploy" или иногда с какой-либо другой ошибкой. Я не смог добиться обоих одновременно.
Наконец, мне пришлось передать аргумент MSBuild, чтобы решить проблему.
Перейти к Изменить определение сборки> Процесс> 3. Дополнительно> Аргументы MSBuild (установлено в) /p:VisualStudioVersion=12.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> -->
Я получил эту ошибку при установке некоторых компонентов VS. К сожалению, ни один из этих ответов не помог мне. Я использую TFS для разработки команд, и у меня нет прав на редактирование определения сборки. Я решил эту проблему, удалив переменные окружения, которые вызвали VS110COMNTOOLS а также VS120COMNTOOLS, Я думаю, что это было установлено с моими компонентами VS.
Я перепробовал все вышеперечисленные решения и до сих пор не повезло. Я слышал, как люди устанавливали Visual Studio на свои серверы сборки, чтобы исправить это, но у меня было всего 5 ГБ свободного места, поэтому я просто скопировал C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio на свой сервер сборки и назвал его день, После этого начал работать, используя Team City 9.x и Visual Studio 2013.
Я обнаружил, что мне не хватает папки WebApplications на моем локальном ПК, я не устанавливал с Visual Studio 2017, как это было при использовании 2012 года.
В моем случае я использовал неправильную версию MSBuild.exe,
Версия, которую вам нужно использовать, зависит от того, какую версию Visual Studio вы использовали для создания своего проекта. В моем случае мне нужно было 14.0 (используя Visual Studio 2015).
Это было найдено в:
C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe
Вы можете посмотреть под:
C:\Program Files (x86)\MSBuild
Чтобы найти другие версии.
Ты найдешь
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets
в файле csproj, для которого эта ошибка появляется. Просто удалите это из csproj и затем соберите.
Я - ничто не помогало в изменении значения v11.0 переменной VisualStudioVersion на v10.0. Изменение переменной в файле.csproj не произошло. Задать это через командную строку не удалось. Так далее...
Закончилось копирование моей локальной папки этой конкретной версии (v11.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