Проблема при указании конфигурации сборки в определении сборки TFS2010 - PullRequest
3 голосов
/ 24 августа 2010

Позвольте мне начать с того, что это новое и первое развертывание TFS с нулевым опытом в Visual Studio в качестве дополнительного бонуса. Мне удалось все установить, и я рад сообщить, что могу даже развернуть как часть процесса сборки в наших различных промежуточных средах, но это то, где дела пошли на юг.

Я пытаюсь настроить отдельные определения сборки для каждого этапа разработки, чтобы я мог воспользоваться преимуществами преобразований конфигурации и использовать детализированные разрешения для тех, кто куда продвигается. В диспетчере конфигурации он настроен таким образом, что каждая конфигурация решения имеет отображение 1-1 в контексте проекта и всегда строит «Любой ЦП». Проблема заключается в том, что когда я использую ключ / p: Configuration = QA в аргументах MSBuild или просто указываю его в 'Items to Build; В разделе параметров процесса сборки сборка завершается неудачно с предупреждением, и, похоже, она не достигает MSDeploy.

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

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MSDeployPublishMethod = WMSVC /p:MsDeployServiceUrl=10.31.60.109 / p: username = tfsdeploy / p: password = lulz / pP = DepISA Bobis / pP = DepISA Bobis AllowUntrustedCertificate = True

Вот предупреждение, которое я получаю в TFS Build Explorer при указании конфигурации для использования.

C: \ Builds \ 2 \ Bob \ Bob - Final Test \ Sources \ Bob \ Bob.sln.metaproj: указанная конфигурация решения "QA | Любой ЦП" недопустима. Укажите допустимую конфигурацию решения, используя свойства Configuration и Platform (например, MSBuild.exe Solution.sln / p: Configuration = Debug / p: Platform = "Any CPU"), или оставьте эти свойства пустыми, чтобы использовать конфигурацию решения по умолчанию.

Решение изначально было создано в VS2008, а локальная копия из VSS была снята с VS2008, а затем перенесена в TFS2010 с использованием VS2010, в значительной степени позволяя MS использовать свое волшебство для преобразования / обновления.

Любая помощь очень ценится.

Ответы [ 2 ]

1 голос
/ 18 января 2011

Проблема, с которой я столкнулся, заключалась в том, что имена конфигураций сборки были разными в файлах .sln и .csproj, и они не могли быть сопоставлены друг с другом, как я думал, что делал в рамках VS2010 ide.1001 *

Это на самом деле довольно простая ошибка.Если вы получили его, проверьте правильность написания в определении сборки, а затем проверьте файлы .sln и .csproj с помощью текстового редактора, например vim / notepad.

0 голосов
/ 17 ноября 2010

Вы исправили это?Я заметил, что некоторые из наших сборок «AnyCPU», а другие «Any CPU», делает отчеты немного интереснее!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...