Когда я запускаю msbuild для создания проекта vc2010, я получаю следующую ошибку:
error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists
on disk.
- msbuild находится в c: \ Program File (x86) \ MSBuild
- HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ MSBuild \ ToolVersions \ V4.0 VCTargetsPath установлен в $ (MSBuildExtensionsPath32) \ Microsoft.Cpp \ v4.0 \
- при запуске msbuild / verbosity: diag как хорошая система показывает MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath, установленный как Environment в начале сборки
- установка MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath в качестве переменных среды в оболочке не приводит к тому, что они отображаются как среда при запуске сборки
Попытка исправлений
- Деинсталлировал .net 4.5, починил .net 4.0
- Задайте MSBuildExtensionsPath32, MSBuildExtensionsPath64, MSBuildExtensionsPath в системных переменных.
Похоже, что MSBuildExtensionsPath32 настроен неправильно, и установка MSBuildExtensionsPath не помогает
SET MSBuildExtensionsPath="C:\Program Files\MSBuild"
Пожалуйста, дайте мне знать, если у вас есть идеи, что блокирует правильную настройку этой переменной.
Ответы:
У меня возникла эта проблема при публикации приложения cocos2d-x с использованием их инструмента командной строки, который вызывает MSBuild. Я использую 64-разрядную версию Win 7, VS2013 express, cocos2d-x версии 3.3, установлен .NET Framework 4.5.
Я исправил проблему, установив следующее перед запуском команды публикации cocos.py:
источник
[Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine")
Для тех, кто не следовал запрещенному порядку MS (см . Ответ Xv ), вы все равно можете решить проблему.
MSBuild использует
VCTargetsPath
для поиска свойств cpp по умолчанию, но не может, потому что в реестре отсутствует это строковое значение.Проверьте строковое значение
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
VCTargetsPath
ключ. Значение должно = "$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\
"Исправить
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
VCTargetsPath
$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\
"Примечание:
HKLM
означаетHKEY_LOCAL_MACHINE
.источник
set VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0
VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v120
HKEY_LOCAL_MACHINE
вам обязательно нужно включить его в regeditset VCTargetsPath=c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140
Недавно у меня была такая же проблема, и после установки разных пакетов в разном порядке она становилась очень беспорядочной. Затем я нашел это репо - https://github.com/felixrieseberg/windows-build-tools
npm install --global windows-build-tools
Он устанавливает инструменты Python и VS Build, необходимые для компиляции большинства узловых модулей. Это сработало!
источник
--production
вариант.npm install --global --production windows-build-tools
В соответствии с инструкциями по установке node-gyp: github.com/nodejs/node-gypДля Visual Studio 2017 и 2019 в Windows 10
Многие ответы здесь применимы к более старым версиям Visual Studio. Что сработало для меня, если я использовал версию сообщества Visual Studio 2017, так это установка переменной среды с именем
VCTargetsPath
и присвоение ей значенияЕсли вы используете версию сообщества Visual Studio 2019,
Другие ответы здесь устанавливают эту переменную,
c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140
но я заметил, что в моей установке Visual Studio в моей папке MSBuild не было папки с именем Microsoft.Cpp. Помните об этом, а также о том, что указанный выше путь предназначен для версии Visual Studio 2017 для сообщества.Кроме того, убедитесь, что ваш путь MSBuild в переменных среды указывает на правильную версию MSBuild, если вы используете версию сообщества Visual Studio 2017,
Если вы используете версию сообщества Visual Studio 2019,
источник
Microsoft Visual Studio\2019\BuildTools
или похожие варианты - и я полагаю, что вместо BuildTools и Community у вас также могут быть Professional и Enterprise.vswhere.exe -products * -property installationPath
выполнит поиск всех комбинаций и вернет расположение всех установленных продуктов.'vswhere.exe' is not recognized as an internal or external command, operable program or batch file.
Установка обновления компилятора Microsoft Visual C ++ 2010 с пакетом обновления 1 для Windows SDK 7.1 исправила
MSB4019
ошибки, которые я получал в Windows7 x64.В ознакомительных сведениях об этом обновлении указано, что рекомендуемый порядок
источник
В 64-разрядных системах MSBuild по умолчанию использует следующие свойства (где C: - SystemDrive):
Если это не так, это означает, что либо у вас установлены настраиваемые сторонние переопределения, либо ваша установка MSBuild повреждена.
Что стоит попробовать:
MSBuildExtensionsPath
вручную, как указано выше (обратите внимание наx86
часть на 64-битных машинах)источник
У меня была эта проблема с версией Visual Studio 2015. Когда я использовал cmake для создания проекта, появилась эта ошибка.
ошибка MSB4019: импортированный проект «D: \ Microsoft.Cpp.Default.props» не найден
Я исправил это, добавив строку
со значением
в пути реестра
источник
MSBuild в виде независимого инструмента сборки, который часто поставляется вместе с другими инструментами. Возможно, он был установлен на вашем компьютере с .NET (более старые версии), Visual Studio (более новые версии) или даже Team Foundation Build.
MSBuild нужны файлы конфигурации, компиляторы и т. Д. (ToolSet), которые соответствуют версии Visual Studio или TFS, которая будет его использовать, а также версии .NET, для которой будет скомпилирован исходный код.
В зависимости от того, как был установлен MSBuild, файлы конфигурации могут находиться по одному или нескольким из этих путей.
Как описано в других ответах, элемент реестра и / или переменная среды должны указывать на путь ToolSet.
Иногда такая операция, как установка инструмента, приводит к неправильной настройке реестра и / или переменной среды. Другие ответы - это все варианты их исправления.
Единственное, что мне нужно добавить, это то, что переменная окружения не работала для меня, когда я перестал использовать конечный \
источник
Записи реестра для ключа MSBuild у меня работали нормально. Важно помнить, что это необходимо делать для 64-разрядных или 32-разрядных веток в зависимости от того, какую версию MSBuild вы используете. Я бы не рекомендовал использовать переменные среды, так как это может вызвать проблемы в разных версиях MSBuild.
Этот файл реестра исправляет это для обоих случаев:
источник
У меня ничего не сработало, кроме установки пути как:
источник
РЕДАКТИРОВАТЬ: это относится к более старым версиям Visual Studio / MSBuild (в частности, MSVC2015?). В более современных версиях MSBuild включен в Visual Studio Build Tools 2019, а компиляторы расположены в разных местах и обнаруживаются по-разному.
Это связано с несоответствием установленных наборов инструментов MSBuild и параметров реестра. Это может произойти, если вы выполнили одно или несколько из следующих действий:
Единственное безопасное и надежное решение - переустановить вашу ОС. Если вашему проекту требуется несколько версий Visual Studio для сборки, сначала установите самую старую версию. . Затем исправьте свой код, чтобы вы могли использовать один единственный инструмент для его создания, иначе вы или ваши коллеги скоро снова окажетесь в том же беспорядке.
Если это не вариант для вас, сначала прочтите https://stackoverflow.com/a/41786593/2279059 чтобы лучше понять проблему и то, что на самом деле делают различные «решения». Затем, в зависимости от вашей версии и настроек Visual Studio, в конечном итоге может помочь один из других ответов или их вариантов.
Еще несколько советов:
источник
У меня сработала установка обновления компилятора Microsoft Visual C ++ 2010 Service Pack 1 для Windows SDK 7.1 . Однако у меня возникли проблемы с обновлением, потому что у меня уже были установлены VS 2010 и VS 2010 SP1. Как упоминалось выше Xv , файл readme.htm содержит решения для наиболее распространенных проблем установки в разделе «Известные проблемы». Я бы следовал инструкциям в readme.htm и перезагружал ваш компьютер после каждой попытки устранения неполадок, потому что некоторые установки записываются в ваш реестр.
источник
В моем случае я добавил переменную среды
VCTargetPath
с путем('\' в конце имеет решающее значение, поскольку файлы решения проекта содержат ссылку на файл «Microsoft cpp target».
Кроме того, начиная с Visual Studio 2017 MSBUILD входит в состав Visual Studio, поэтому
PATH variable
необходимо обновить его с помощьюОбновление
VCTargetPath
иPATH
переменные MSBUILD и сборка исправили ошибку.источник
Я столкнулся с этой ошибкой, написав сценарий сборки, который помещал MSBuild в% PATH% после рекурсивного рытья в папке C: \ Windows \ Microsoft.NET для любых найденных файлов MSBuild.exe. Последним найденным совпадением был каталог, указанный в пути. Поскольку
dir
команда попадет вFramework64
папку после того, какFramework
я получу одну из 64-битных сборок MSBuild на моем пути. Я пытался создать решение Visual Studio 2010 и в итоге изменил свою строку поиска сC:\Windows\Microsoft.NET
на,C:\Windows\Microsoft.NET\Framework
чтобы получить 32-битный MSBuild.exe. Теперь мой файл решения строится.источник
Я просто добавил
VCTargetsPath={c:\...}
в качестве переменной среды свою работу в Hudson.источник
Для записи, файл
Microsoft.Cpp.Default.props
может изменить переменную envVCTargetsPath
и сделать последующее использование этой переменной неверным. У меня была эта проблема, и я решил ее, установивVCTargetsPath10
иVCTargetsPath11
на то же значение, что иVCTargetsPath
.Это должно быть адаптировано в соответствии с версией VS, которую вы используете.
источник
Я вижу это в среде VS2017.
VsDevCmd.bat
Сначала вызывается мой сценарий сборки , и для решения этой проблемы я устанавливаюVCTargetsPath
переменную среды послеVsDevCmd
и перед вызовом MSBuild:источник
Добавление к ответу Криса Гонга о VS2017 / 2019 выше (у меня еще нет разрешения на комментарии).
Если установлены VS 2019 Build Tools, а не полная Visual Studio, пути к файлам немного отличаются. VCTargetsPath тогда должен быть
Также обратите внимание на завершающую обратную косую черту - требуется по крайней мере в моем случае (TFS2017, инструменты сборки VS2019). Соответствующее изменение и в записи PATH.
источник
Я столкнулся с той же проблемой с MSBuild для VS 17
Я решил это, выполнив следующие действия:
В моем случае
Microsoft.Cpp.Default.props
файл был расположен по адресу,C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets
поэтому я создалVCTragetsPath
строку в реестреHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
со значениемC:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\IDE\VC\VCTargets
Я также запустил свой Jenkins как администратор
Это решило мою проблему.
источник
Вместо того, чтобы устанавливать фиксированный путь, сначала попробуйте это в командной строке после сборки:
Переменная '$ (VCTargetsPath)' кажется связанным с C ++ макросом visual-studio-macro, который не показан в c # -sdk-projects как макрос, но все еще доступен там.
источник