Ответ 1
Попробуйте удалить, а затем снова добавить файл, чтобы восстановить файл sln. Таким образом, мне удалось добиться успеха. По какой-то причине мой файл sln был некорректным.
Team Foundation Server 2010/MSBuild: ошибка при анализе вложенного раздела проекта в файле решения
Я пытаюсь создать ночную сборку для одной из моих продуктов компании. Когда я выполняю сборку, она терпит неудачу после 45 или около того секунд, выдавая ошибку "Ошибка при анализе вложенного раздела проекта в файле решения.
Это журнал из сборки:
Удалить каталог бинарных файлов
00:17 Удалить рабочее пространство
00:00 Удалить каталог источников
00:00 Создать рабочее пространство
00:18 Получить рабочее пространство
00:01 Создать ярлык метки [label] (версия W60_2_VMCORPTFS01; CL\me) была успешно создан.
00:04 Компиляция, тестирование и связывание Изменения и рабочие элементы
00:04 Компиляция и тестирование
00:03 Запустите MSBuild для проекта C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe /nologo/noconsolelogger "Е:\localstore\Productname_2.0\Product\Product.sln" /m: 1/fl /flp: "logfile=e:\localstore\ThisSpecificBuild\Product\Product.log;encoding=Unicode;verbosity=normal" /Р: SkipInvalidConfigurations = истина /Р: OutDir = "C:\Строит\2\Продукт\ThisSpecificBuild\Binaries \" /Р: Конфигурация = "Отладка" /p: Платформа = "Любой процессор" /p:VCBuildOverride= "e:\localstore\Productname_2.0\Product\Product.sln.Any CPU.Debug.vsprops" /Дл: WorkflowCentralLogger, "C:\Program Файлы \Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll"; "многословие = Нормальный; BuildUri = vstfs:///Build/Build/2934; InformationNodeId = 1175609; TargetsNotLogged = GetNativeManifest, GetCopyToOutputDirectoryItems, GetTargetPath; TFSUrl = HTTP://локальный: 8080/TFS/DefaultCollection;" * WorkflowForwardingLogger, "C:\Program Файлы \Microsoft Team Foundation Server 2010\Tools\Microsoft.TeamFoundation.Build.Server.Logger.dll"; "Многословность = Нормальный;"
00:00 Построен $/OMS/Отрасли/Product_2.0/Продукт/Product.sln для целей по умолчанию. е:\localstore\ThisSpecificBuild\Продукт\Product.sln(1586): ошибка при анализе вложенных раздел проекта в файле решения.
И это журнал из MSBuild:
Сборка началась 7/6/2011 11:53:34 AM. е:\localstore\ThisSpecificBuild\Продукт\Product.sln(1586): Ошибка файла решения MSB5009: ошибка синтаксический анализ вложенного раздела проекта в файл решения.
Сборка FAILED.
е:\localstore\ThisSpecificBuild\Продукт\Product.sln(1586): Ошибка файла решения MSB5009: ошибка синтаксический анализ вложенного раздела проекта в файл решения.
0 Warning(s) 1 Error(s)Истекшее время 00: 00: 00.19
Решение построено правильно из Visual Studio.
Ответы
Ответ 2
Я просто провел весь день на этом и нашел способ. Я нашел запись в файле .sln, ссылаясь на проект, которого не было в решении. Этот GUID проекта phantom также не упоминался нигде в файле .sln.
Поиск возвратил пару трюков, таких как http://social.msdn.microsoft.com/Forums/da-DK/msbuild/thread/55ab07ef-9179-4cc6-b2d0-63fcf088d8ba
Те "казалось" не работали, поскольку локальные сборки все же преуспели, и Team Build все еще не удалось. Затем я заметил, что строка 6199 в моем решении всегда виновата, хотя эта строка менялась со временем. Оказалось, что в определении Team Build было Чистое рабочее пространство установлено Вывод вместо Все. После того как вы изменили его на Все, Team Build снова работала.
Ответ 3
Если вы изменили файл вручную или с помощью объединенного инструмента, может быть оставлена пустая строка, что в порядке с компиляцией Visual Studio, но сбой в сборках автоматизации.
Ответ 4
Для меня переименование моего проекта и сокращение имен проектов помогло. Похоже, что в зависимости от того, какой целевой каталог tfs отбрасывает ваше решение, макс. длина 256 для имен файлов может быть превышена.