Msbuild error msb4025 не удалось загрузить файл проекта отсутствует корневой элемент
Когда я запускаю свою сборку TeamCity с единственным этапом сборки, являющимся бегуном типа Visual Studio (sln), я получаю следующую ошибку:
Это на выделенном сервере CI под управлением TeamCity Professional 8.1.1 (сборка 29939). На этом сервере есть еще несколько успешно работающих сборок.
Странно то, что эта же сборка успешно работает в TeamCity на моей машине разработчика. Я последовал ответу на аналогичный вопрос и скопировал указанные папки, но это не помогло.
Я уверен, что файл проекта / решения недействителен, потому что в дополнение к сборке, запущенной в моем блоке разработчика, я открыл решение в Visual Studio и без проблем построил его там.
Я только что исправил это.
Найдите в файле Test.sln теги Project или EndProject, которые не закрыты. Для нас EndProject отсутствовал, и он сломался в teamcity, но без проблем в Visual Studio.
В нашем случае это была дублирующаяся ссылка на проект в файле решения (вызванная почти одновременной фиксацией и автоматическим слиянием).
В нашей ситуации проблема заключалась в указании версии ToolsVersion, которая не была установлена на этом компьютере. (14, которые есть у VS2015, но у VS2017 нет по умолчанию)
В моем случае после слияния в файле .sln было несоответствие строк под
Раздел. Проще говоря, после слияния было добавлено несколько дополнительных строк. Итак, если вы объединились, сравните два файла решения вручную. Вы можете начать с общих номеров строк в обоих файлах.
В другом случае
У нас были пустые строки - поэтому убедитесь, что все пустые строки удалены!
Надеюсь, это поможет и другим!
У меня такая же ошибка с Дженкинсом. Оказывается, корневая папка Jenkins была установлена в C: \ Program Files (x86) \, и у нее не было доступа на запись в каталоги bin и obj.
Ошибка: ошибка MSB4025: не удалось загрузить файл проекта. Данные на корневом уровне недействительны.
Я запустил cmd от имени администратора и запустил следующее: «C: \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ MSBuild.exe» «C: \ Program Files (x86) \ Jenkins \ workspace \ BuildBI_1 \ Reports \ Test \ ReportsTests .sln "/ t: Build / p: RunOctoPack = true
И это дало мне понять, что нельзя писать в bin и obj.
Используйте MSBuild , чтобы определить основную проблему:
Подарил мне эту красоту с правильным номером строки ошибки :
Если к msbuild нельзя получить доступ из командной строки / powershell, попробуйте найти MSBuild.exe, поставляемый с VisualStudio, например C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\amd64\MSBuild.exe .
Сам VisualStudio кажется очень «терпимым» к ошибкам / несоответствиям в файле решения, поэтому его открытие в VS не гарантирует правильности файла sln .
когда я запускаю сборку TeamCity с единственным шагом сборки типа runner Visual Studio( sln), я получаю следующую ошибку:
Это на выделенном сервере CI под управлением TeamCity Professional 8.1.1 (build 29939). На этом сервере есть несколько других успешно выполняемых сборок.
нечетный бит заключается в том, что одна и та же сборка успешно выполняется на TeamCity на моей машине dev. Я следовал ответ к подобному вопросу, и скопировал указанных папок, но это не помогло.
Я уверен, что файл проекта/решения не является недопустимым, потому что в дополнение к сборке, запущенной в моем окне dev, я открыл решение в Visual Studio и построил его там без проблем.
Я только что исправил это.
посмотрите внутрь теста.sln-файл для тегов Project или EndProject, которые не закрыты. Для нас EndProject отсутствовал, и он сломался в teamcity, но никаких проблем в Visual Studio.
в нашем случае это была дублирующая ссылка на проект в файле решения (вызванная почти одновременными коммитами и автоматическим слиянием).
в моем случае, после слияния, в .файл sln, это было несоответствие строк под
. Ясными словами, после слияния было добавлено несколько дополнительных строк. Итак,если вы объединились, сравните два файла решения вручную. Вы можете начать с общих номеров строк в обоих файлах.
в другом случае
У нас были пустые строки-поэтому убедитесь, что все пустые строки удалены!
надеюсь, это поможет еще кому-то!
Я получил ту же ошибку с Дженкинсом. Оказывается, корневая папка Jenkins была установлена в C:\Program Files (x86)\ и у него не было доступа на запись в каталоги bin и obj.
ошибка: ошибка MSB4025: не удалось загрузить файл проекта. Данные на корневом уровне, является недействительным.
Я запустил cmd как администратор и запустил это: "Файлы C:\Program (для x86)\MSBuild с\14.0\Бин\в MSBuild.exe "" C:\Program файлы (x86)\Jenkins\workspace\BuildBI_1\Reports\Test\ReportsTests.sln " / t:сборка /p: RunOctoPack=true
и это дало мне подсказки о том, что я не могу писать в bin и obj.
в нашей ситуации проблема заключалась в указании ToolsVersion, который не был установлен на этой машине. (14, который VS2015 имеет, но VS2017 не имеет по умолчанию)
Это сработало для меня- Вы можете установить инструменты сборки для Visual Studio 2017, обязательно выберите c++ tools, Windows 10 SDK и MSBuild и ваш набор.
любая идея, какой файл я должен посмотреть в мои решения?
любая помощь была бы очень признательна. :)
Я использую VS 2008 и Visual Build Pro 6.7.
убедитесь, что любой XML-файл (или любой файл, который будет интерпретироваться как XML-файл visual studio) имеет правильную структуру XML - то есть один корневой элемент (с любым именем, я использую rootElement в моем примере):
в моем случае это был Ремчуков.расширением vcxproj.файл пользователя, который вызывал проблему (он был пустым) после сбоя. Я переименовал его и проблема ушла.
вы также получите "корневой элемент отсутствует", когда бомба поражает :). BOM = Знак порядка байтов. Это дополнительный символ, который добавляется в начало файла, когда он сохраняется с неправильной кодировкой.
Это может иногда происходить в Visual Studio при работе с XML-файлами. Вы можете либо закодировать что-то, чтобы удалить его из всех ваших файлов, либо, если вы знаете, какой файл вы можете заставить visual studio сохранить его с определенной кодировкой (utf-8 или ascii IIRC).
Если вы откройте файл в Редакторе, отличном от VS (попробуйте notepad++), вы увидите два забавных символа перед XML-декларация.
- "файл" > "Дополнительные параметры сохранения" > выбрать соответствующую кодировку
- Файл > Сохранить как > сохранить имя файла, щелкните стрелку вниз справа от кнопки "Сохранить", чтобы выбрать кодировку
в моем случае.Я получал ошибка отсутствует элемент указывая на . В то время он выглядел примерно так.--7-->
тогда я просто добавил configuration тег, который фактически обертывает весь xml. Теперь работает отлично для меня
эта ошибка может иногда возникать при редактировании некоторых параметров цепочки инструментов проекта Atmel Studio 6.1.2730 SP2.
в моем случае я попытался отредактировать свойства проекта > Toolchain > Linker > Общие настройки с "всеми конфигурациями", выбранными в конфигурации. Когда я проверил или снял флажок, появилось диалоговое окно с ошибкой. Однако я обнаружил, что могу сделать те же изменения, если я сделал их только для одной конфигурации сборки за раз; т. е. только с "Debug" или "Release" выбрано вместо "все конфигурации".
интересно, что позже я смог редактировать те же настройки компоновщика даже с выбранными "всеми конфигурациями". Я не знаю, что изменилось в моем проекте, что сделало это возможным.
в моем случае, файл C:\Users\xxx\AppData\Local\PreEmptive Solutions\Dotfuscator Professional Edition.0\dfusrprf.xml был полон NULL.
Я удалил его; он был воссоздан при первом запуске программы Dotfuscator, и после этого нормальность была восстановлена.
У меня был синий экран при запуске Visual Studio 2013, при перезапуске я намеревался запустить снова свой проект, но у меня всегда была эта ошибка headius. во всяком случае
внутри существует папка с именем проекта+ некоторые созданные ГРАФИЧЕСКИЙ ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ Услуга.ServerHostLoader_Url_u2jn0xkgjf1th0a3i2v03ft15vj4x52i
Это папка, которую я удалил, и теперь я могу снова запустить проект.
вы также можете выполнить поиск файла. Перейдите в каталог проекта с помощью PowerShell и запустите Get-FileMissingRoot:
в моем случае я обновился до VS2017 и хотел построить все проекты с MSBuild 4 с моим скриптом сборки (который использовал MSBuild 3.5, когда мы использовали VS2015). Это обновление MSBuild оказалось прекрасным для настольных приложений Windows, но для Windows CE с compact framework дало бы мне эту запутанную ошибку. Возврат к MSBuild 3.5 для Windows CE projects исправил проблему для меня.
У меня была бомба .кстати, файлы csproj и удалили их для всех проекты в решении, которое не будет строить, но это не помогло.
Ho я просто решил эту проблему, перейдя в проводник управления версиями и выбрав проект проблемы, щелкните правой кнопкой мыши и выберите опцию получить конкретную версию в расширенном меню. А затем выберите тип в качестве последней версии и отметьте следующие два флажка и нажмите кнопку Get. Затем я обновил решение, и мой проект вернулся к жизни, и проблема исчезла. Обратите внимание, что это может перезаписать ваши локальные проекты, так что ваши текущие изменения могут потерять. Так что если у вас нет никаких проблем с локальную копию, тогда вы можете попробовать это. Надеюсь, это поможет
буква диска ОС:\Users\USER NAME\AppData\Local\Microsoft\WebsiteCache
для получения дополнительных советов visual studio посетите Мой Блог
Я получил эту проблему в проекте веб-API. Наконец выяснил, что это было в моих комментариях к методу"///". У меня есть эти комментарии, установленные для автоматического создания документации для методов API. Что-то в моих комментариях заставило его сойти с ума. Я удалил все возвраты каретки, специальные символы и т. д. Не совсем уверен, что ему не понравилось, но это сработало.
в моем случае файлы RDLC работают с файлами ресурсов (.resx), у меня была эта ошибка, потому что я не создал соответствующий файл resx для моего отчета rdlc.
моим решением было добавить файл .resx внутри App_LocalResources таким образом:
У меня было несколько массовых сбоев сообщества VS2015.
удалить все .csproj файл.пользовательские файлы
которые были полны нулевых символов, а также Эти
Я просто прокомментировал обрезанный код ниже в файле проекта (.csproj), и проблема была исправлена.
в моем случае xxxx.pubxml.пользователь не был загружен при попытке опубликовать приложение. Я удалил файл и перезапустил Visual studio, затем создал новый профиль для его публикации, проблема решена и опубликована успешно.
в моем случае, я получил эту ошибку из-за пустой . Это привело к сбою диспетчера пакетов NUGET и отображению ошибки отсутствует корневой элемент. Решение состояло в том, чтобы скопировать элементы из другого непустого файла, а затем изменить его в соответствии с потребностями.
пример (пакеты.config):
в моем случае я использовал vs 2010 с crystal report. Innerexception показал корневой элемент отсутствует ошибка. Перейти в каталог как C:\Users\sam\AppData\Local\dssms\dssms.vshost.exe_Url_uy5is55gioxym5avqidulehrfjbdsn13\1.0.0.0 который приведен в innermessage и убедитесь, что пользователь.config-это правильный XML (мой был пуст по какой-то причине).
У меня есть 2017 Visual Studio Mac Community Edition. Мне, наконец, удалось найти решение через несколько часов (больно!).
мое решение связано с тем, что фреймворки, связанные с Visual Studio, старые или сломанные. Я нашел это, потому что я попытался создать новое решение Mac с помощью Cocoa, и он сказал:"не удалось сохранить решение". Затем я попытался создать решение для Android и она работает нормально. Перейдите в " Finder "и" Go "- > "перейти в папку", затем перейдите в"Библиотека/фреймворки". Я удалил mono.рамки и рамки, связанные с Xamarin, потому что я считаю, что эти рамки Xamarin сломаны.
затем удалил Visual Studio и переустановил его. Теперь все работает нормально!
была эта проблема входа в RDP на старом сервере VM fount время (часы) было установлено 2 часа. (и неправильный часовой пояс) в хост-системе. исправил и все было хорошо. Теория поцелуев.. :)
Solution will build. It worked with VS2017, but even installing VS2019 side-by-side breaks the build. Changing the versions to 16.0 does not help either.
Actual behavior
Solution fails to build with MSB4025.
Environment data
msbuild /version output:
OS info: Windows 10 Enterprise 1809 17763.437
If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc):
Developer command prompt for VS2019 16.0.2
EDIT:
VS2019 builds the msbuildissue.sln correctly and msbuild msbuildissue.sln works very well.
The text was updated successfully, but these errors were encountered:
rainersigwald commented Apr 30, 2019
It worked with VS2017, but even installing VS2019 side-by-side breaks the build.
Can you elaborate on this, please? What error do you get when you build using MSBuild from VS2017 after the 2019 installation?
ljani commented May 1, 2019
It worked with VS2017, but even installing VS2019 side-by-side breaks the build.
Can you elaborate on this, please? What error do you get when you build using MSBuild from VS2017 after the 2019 installation?
Also it occurred to me that I have not tried running msbuild from Developer Command Prompt for VS 2017 , only from Developer Command Prompt for VS 2019 and Azure DevOps Server 2019 continuous integration build, which is probably picking up 2019 as default as well.
Ah, thanks. I'll close this as a duplicate.
rainersigwald commented May 1, 2019
Also it occurred to me that I have not tried running msbuild from Developer Command Prompt for VS 2017 , only from Developer Command Prompt for VS 2019 and Azure DevOps Server 2019 continuous integration build, which is probably picking up 2019 as default as well.
mwpowellhtx commented Oct 12, 2019 •
@rainersigwald I think I've stumbled into the same sort of issue after installing VS2019, then iterating back on a VS2017 build pipeline. Fails restoring an internal dotnet CLI tool that was working seamlessly, seems prior to VS2019 installation in our estimation. Where do we set the ToolsVersion ? In the project file(s)? We can set this in a Directory.Build.props ?
mwpowellhtx commented Oct 12, 2019
So. Looking for workarounds, resolutions. Besides potentially need to install and/or re-install SDKs, runtimes, etc. Haven't gotten quite that far in my troubleshooting. Short of that, crude answer is for us to visit each of our .csproj project files and add the ToolsVersion attribute in the appropriate version? I assume that's 15.0 for VS2017? Is there a more elegant way to do that in swath? i.e. through Directory.Build.props, for instance, by convention, as contrasted with by specification?
labilbe commented Nov 25, 2020
Otherwise you can specify ToolsVersion="Current"
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
I am trying to build gperftools on Windows with VS2017. I have written a script, where do the following steps:
- Download the latest release of gperftools from github.
- Unzip the downloaded zip archive.
- Call %ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat amd64_x86
- Start building with msbuild gperftools.sln /t:Rebuild /p:Configuration=Release;Platform=x64;PlatformToolset=v141
What I get is this output:
Microsoft (R) Build Engine version 15.7.180.61344 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 9/4/2018 2:56:48 PM.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.Build FAILED.
MSBUILD : error MSB4025: The project file could not be loaded. Root element is missing.
Time Elapsed 00:00:00.03
Now I tried to solve it in another way. The first thing I tried was to upgrade the solution first, so
- Download the latest release of gperftools from github.
- Unzip the downloaded zip archive.
- Call %ProgramFiles(x86)%\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvarsall.bat amd64_x86
- devenv /Upgrade gperftools.sln
- Start building with msbuild gperftools.sln /t:Rebuild /p:Configuration=Release;Platform=x64;PlatformToolset=v141
This is what I am getting now:
Microsoft (R) Build Engine version 15.7.180.61344 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
Build started 9/4/2018 3:02:40 PM.
Project "C:\somepath\gperftools-gperftools-2.7\gperftools.sln" on node 1 (Rebuild target(s)).
C:\somepath\gperftools-gperftools-2.7\gperftools.sln.metaproj : error MSB4126: The specified solution configuration "Release|x64" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [C:\somepath\gperftools-gperftools-2.7\gperftools.sln]
Done Building Project "C:\somepath\gperftools-gperftools-2.7\gperftools.sln" (Rebuild target(s)) --
FAILED.Build FAILED.
"C:\somepath\gperftools-gperftools-2.7\gperftools.sln" (Rebuild target) (1) ->
(ValidateSolutionConfiguration target) ->
C:\somepath\gperftools-gperftools-2.7\gperftools.sln.metaproj : error MSB4126: The specified solution configuration "Release|x64" is invalid. Please specify a valid solution configuration using the Configuration andPlatform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [C:\somepath\gperftools-gperftools-2.7\gperftools.sln]
Time Elapsed 00:00:00.12
When I opened the solution I could not see any Configuration for x64. So, as far as I understand, there is no way to build it in x64 with VS2017?
Читайте также: