MSBUILD Ошибка MSB4025 в шаге сборки TeamCity для Visual Studio

Когда я запускаю сборку TeamCity с единственным этапом сборки типа runner type Visual Studio (sln), я получаю следующую ошибку:

C:\TeamCity\buildAgent\work\4978ec6ee0ade5b4\Test\Code\Test.sln(2, 1): error MSB4025: The project file could not be loaded. Data at the root level is invalid. Line 2, position 1.

Это выделенный сервер CI, на котором запущен TeamCity Professional 8.1.1 (сборка 29939). На этом сервере существует несколько других успешно работающих сборок.

Нечетный бит заключается в том, что одна и та же сборка успешно запускается на TeamCity на моей машине dev. Я выполнил ответ по аналогичному вопросу и скопировал указанные папки, но это не помогло.

Я уверен, что файл проекта/решения не является недопустимым, поскольку в дополнение к сборке, запущенной в моем блоке dev, я открыл решение в Visual Studio и без проблем создал его там.

Любые предложения?

Ответ 1

Я просто исправил это.

Просмотрите файл Test.sln для тегов Project или EndProject, которые не закрыты. Для нас EndProject отсутствовал, и он разбился о teamcity, но никаких проблем в Visual Studio не было.

Ответ 2

Кажется, что сообщение об ошибке TeamCity будет происходить для любого количества причин. В моем случае проблема возникла из-за того, что строка внутри раздела GlobalSection (NestedProjects) ссылалась на проект Guid, который не касался какого-либо проекта, определенного в файле решения.

Как и в предыдущем посте, у меня не было никаких проблем в Visual Studio. У меня появилось более полезное сообщение об ошибке, которое позволило мне узнать, какова реальная проблема, когда я построил с помощью msbuild.

См. https://therightjoin.wordpress.com/2014/07/04/msb4025-the-project-file-could-not-be-loaded-data-at-the-root-level-is-invalid-error-when-building-ssdt-project-in-teamcity для другого примера и где использование msbuild помогло идентифицировать истинную проблему.

Ответ 3

В нашем случае это была дублируемая ссылка на проект в файле решения (вызванная почти одновременными фиксациями и автоматическим слиянием).

Ответ 4

В моем случае после слияния в .sln файле это было несоответствие строк под

GlobalSection(NestedProjects) = preSolution  

{6B971E15-6B61-4AA8-9B93-9639C23269C3} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}

{54D14F01-D576-4DE6-9404-D21AD0DC4916} = {9A14E7EF-3FA1-4B9A-B413-C550B3E5AC62}

... (was some extra entry here )
...

 EndGlobalSection

раздела. В ясных словах после слияния добавились дополнительные строки. Итак, если вы слились, сравните два файла решения вручную. Вы можете начать с общих номеров строк в обоих файлах.

Ответ 5

В другом случае

У нас были пустые строки - поэтому убедитесь, что пустые строки удалены!

Надеюсь, это поможет и другим!

Ответ 6

У меня такая же ошибка с Дженкинсом. Оказывается, корневая папка Jenkins была установлена в C:\Program Files (x86)\и не имела доступа к записи в каталоги bin и obj.

Ошибка: Ошибка MSB4025: файл проекта не может быть загружен. Данные на корневом уровне недействительны.

Я запустил cmd как Administrator и запустил это: "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 = истина

И это дало мне понять, что я не могу писать в bin и obj.