Как я могу заставить TFS2010 запускать MSDEPLOY для меня через MSBUILD?

В Vishal Joshi есть отличная версия PDC, в которой описываются новые функции MSDEPLOY в Visual Studio 2010, а также развертывание приложения в TFS. (Также есть отличный разговор от Скотта Гензельмана, но он не входит в TFS).

Вы можете использовать MSBUILD в TFS2010 для вызова MSDEPLOY для развертывания вашего пакета в IIS. Это делается с помощью параметров для MSBUILD.

В этом разделе объясняются некоторые параметры командной строки, такие как:

/p:DeployOnBuild /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:MSDeployPublishMethod=InProc /p:MSDeployServiceURL=localhost /p:DeployIISAppPath="Default Web Site" 

Но где документация для этого – я не могу найти?

Я проводил весь день, пытаясь заставить это работать, и не может понять все правильно и продолжать приводить к различным ошибкам. Если я запустил cmd файл пакета, он отлично развернется. Если я запустил WebDeploy через Visual Studio, он также отлично работает.

Но я хочу, чтобы все развертывание выполнялось через msbuild с использованием этих аргументов, а не отдельный вызов msdeploy или запуск пакета .cmd файла. Как я могу это сделать?

PS. Да, у меня работает Web Deployment Agent Service . У меня также есть служба управления, работающая под IIS. Я пробовал использовать оба.


Арги, которые я использую:

 /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:Configuration=Release /p:CreatePackageOnPublish=True /p:DeployIisAppPath=staging.example.com /p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd /p:AllowUntrustedCertificate=True 

давая мне:

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (2660): VsMsdeploy не удалось. (Удаленный агент (URL https://staging.example.com: 8172 / msdeploy.axd? Site = staging.example.com ). Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере.) Ошибка: удаленный агент (URL https: //staging.example. com: 8172 / msdeploy.axd? site = staging.example.com ) не удалось связаться. Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере. Был получен неподдерживаемый ответ. Заголовок ответа ‘MSDeploy.Response’ был ”, но ожидалось ‘v1’. Удаленный сервер ответил на ошибку: (401) Неавторизованный.

Ответ на IIS7 + ….

Хорошо, вот что я сделал. Более или менее, после сообщения Саймона Уивера в этой теме / вопросе.

Но когда дело доходит до настроек MSBuild, большинство пользователей здесь используют следующие настройки: /p:MSDeployPublishMethod=RemoteAgent который НЕ ПРАВИЛЬНО для IIS7. Использование этого параметра означает, что TFS пытается подключиться к url: https://your-server-name/MSDEPLOYAGENTSERVICE Но для доступа к этому URL-адресу пользователь для аутентификации должен быть администратором. Который перевернулся. (И вам нужно, чтобы правило администратора было отменено). Думаю, этот URL-адрес для IIS6.

Вот стандартное сообщение об ошибке при попытке подключения с помощью RemoteAgent:

Стандарт 401 Frak Off u suck RemoteAgent, ошибка

C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588): Не удалось выполнить задачу развертывания сети (удаленный агент (URL http: // your-web- сервер / MSDEPLOYAGENTSERVICE ). Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере.) Убедитесь, что имя сайта, имя пользователя и пароль верны. Если проблема не устранена, обратитесь к местному администратору или администратору сервера. Сведения об ошибке: Удаленный агент (URL-адрес http: // your-web-server / MSDEPLOYAGENTSERVICE ) не смог связаться. Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере. Был получен неподдерживаемый ответ. Заголовок ответа «MSDeploy.Response» был «V1», но ожидалось «v1». Удаленный сервер ответил на ошибку: (401) Неавторизованный.

Итак, вам нужно изменить свой MSDeployPublishMethod на это:

 /p:MSDeployPublishMethod=WMSVC 

WMSVC означает службу диспетчера Windows. Это, в основном, более новая shell над удаленным агентом, но теперь позволяет нам исправить предоставление имени пользователя и пароля .. где пользователь НЕ должен быть администратором! (радость!) Итак, теперь вы можете исправить набор, к которому пользователи хотят иметь доступ … на веб-сайт.

введите описание изображения здесь

Теперь он также пытается попасть в URL-адрес: https://your-web-server:8172/MsDeploy.axd <- это ТОЧНО, что делает окно Publish Visual Studio 2010! (OMG -> PENNY DROPS !! BOOM!)

введите описание изображения здесь

И вот мои окончательные настройки MSBuild:

 /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=your-server-name /p:DeployIISAppPath=name-of-the-website-in-iis7 /p:username=AppianMedia\some-domain-user /p:password=JonSkeet<3<3<3 /p:AllowUntrustedCertificate=True 

Обратите внимание, что имя пользователя имеет в нем имя домена? Мне нужно это, там. Кроме того, на моем снимке я разрешил нашим пользователям DOMAIN доступ к сайту для управления. Таким образом, моя новая учетная запись пользователя, добавленная мной (TFSBuildService), имеет членство в группе « Domain Users » ... так вот как все работает.

Теперь - если вы все это прочитали, у вас есть lolcat (потому что они SOOOOOOOO 2007) ....

введите описание изображения здесь

Вот шаги, которые, наконец, сработали для меня. Я хотел получить работу с RemoteAgent, но не мог получить работу независимо от того, что я пробовал.

Вам не обязательно делать это так, но я так понял

  • Настройка WMSVC
  • Убедитесь, что служба запущена
  • Настройте пользователя IIS (нажмите «ТОЛЬКО САМЫЙ СЕРВЕР» в IIS) и перейдите к «Диспетчеру IIS». Я предлагаю сделать это иначе, чем имя вашего windows.
  • Убедитесь, что учетная запись пользователя WMSVC (LOCAL SERVICE для меня) имеет права на запись в каталог IIS, который вы используете
  • В моем случае я использую SSL-сертификат (хотя он и попадает в localhost).

Помните, что это все аргументы MSBUILD, добавленные в определении сборки TFS

 /p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd /p:username=sweaveriis /p:password=abcd1234 /p:DeployIisAppPath=staging.example.com/virtual_directory_name /p:AllowUntrustedCertificate=True 

Примечание. Staging.example.com на самом деле является локальным полем с входом файла hosts, указывающим на 127.0.0.1. Localhost, вероятно, тоже будет работать здесь.

Полезные статьи:

Устранение неполадок MSDeploy

Больше проблем

К сожалению, на данный момент информации об этом мало. Однако я дам вам несколько советов в конце этого сообщения.


О вашей проблеме, я видел это раньше, когда я пытался развернуть с использованием MSDeploy, и учетная запись, в которой я работала, не имела разрешений на выполнение развертывания на целевой машине. Поэтому вам нужно взглянуть на учетную запись, в которой работают ваши сборки, и посмотреть, имеет ли эта учетная запись права на развертывание на целевой машине. Если нет, то у вас есть несколько вариантов; предоставить пользователю сборщика права или передать имя пользователя / пароль.

Если вы хотите передать значения, то вам нужно будет определить элемент с именем MsDeployDestinationProviderSetting и его метаданные должны будут содержать необходимые значения.

Поэтому в вашем файле проекта (или через переданные свойства) определите что-то вроде следующего.

  USERNAME-HERE PASSWORD-HERE  

О том, где вы можете найти документацию, как я уже говорил, пока еще немного. Но так как весь трафик веб-публикаций захвачен в целях и задачах MSBuild, вы можете узнать много, если вы знакомы с MSBuild. Если вы посмотрите файлы .csproj (или .vbproj) для веб-проектов, созданных с помощью Visual Studio 2010, вы увидите следующее заявление:

  

Это импортирует файл, расположенный в папке %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets , и этот файл, в свою очередь, импортирует %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets

Поэтому, чтобы подробно изучить эту тему сейчас, вам нужно проверить эти файлы и узнать сами.


Я собираюсь работать над чем-то, что будет подробно описывать эти технологии, но это не будет долгое время, и мне еще многое предстоит выяснить о себе.

Можете ли вы попробовать найти имя пользователя / пароль и сообщить мне, если он сработает для вас?

У меня была аналогичная проблема, и решение должно было иметь следующий параметр:

/ p: MSDeployPublishMethod = RemoteAgent

Вот все параметры, которые я использовал.

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MSDeployPublishMethod = RemoteAgent / p: MsDeployServiceUrl = http: // my-server-name / p: username = myusername / p: password = mypassword

ПРИМЕЧАНИЕ. Я не использую DeployIisAppPath, потому что я создаю решение и пытаюсь создать сразу три веб-приложения. Также я думаю, что ваш MsDeployServiceUrl должен быть просто http://staging.example.com

Похоже, что при использовании InProc (который может быть по умолчанию) MSDeployPublishMethod MSBuild игнорирует MsDeployServiceUrl и всегда пытается развернуть его на локальный сервер. Я изменил его на RemoteAgent, и все три моих веб-приложения были успешно развернуты. Я заметил, что файл пакета является nolonger, содержащимся в папке MyWebApplication_Package, но для меня это не имеет большого значения.

Обратите внимание, что вы также можете установить DeployTarget = Package – это подготовит пакет, но не разложит его сразу. Для получения дополнительной информации см. Это сообщение в блоге .

Для меня проблема заключалась в том, что Web Deployment Agent Service не запускалась.

Простой net start msdepsvc исправил его. Вы также можете настроить режим автозапуска на этот сервис.

Аргументы, которые я использую:

 /p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MSDeployServiceUrl=stagingserver /p:DeployIisAppPath=test.local /p:UserName= 

Вам нужно только указать имя сервера, а не полный путь (не нужно http).

Обратите внимание, что UserName остается пустым, чтобы обойти ошибку с помощью проверки подлинности NTLM (таким образом он использует учетные данные агента сборки TFS для развертывания). см. принятый ответ здесь

Вот как я получил его на работу. Это было с Webdeploy 2.0. Я развертываю в том же домене с нашей машины для сборки на сервере Windows Server 2008 r2 сервера веб-сервера dev. Учетная запись, которую я использую для развертывания, – это учетная запись службы в домене с правами администратора на обеих машинах. Мое решение включает в себя пару единичных тестовых проектов, проект mvc3 и пару библиотек в рамках решения. Если вы не установите MVC3 на сервере, который вы развертываете, обратитесь за помощью к http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio .

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: DeployIisAppPath = “Веб-сайт по умолчанию / YourpplicationNameHere” /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd / p: AllowUntrustedCertificate = True / p: UserName = yourDomain \ buildaccount / p: Пароль = пароль

  1. Элементом, с которым я столкнулся сначала, были цитаты вокруг «Default Web Site / YourpplicationNameHere». Это дает частичную ошибку:

    MSBUILD: ошибка MSB1008: Можно указать только один проект.

    Это происходит, когда нет кавычек вокруг веб-сайта по умолчанию / YourApplicationNameHere

  2. Следующая ошибка, которую я получил, была из-за неправильного имени пользователя и пароля в моих учетных данных для развертывания. Он дал эту ошибку:

    C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588): Не удалось выполнить задачу развертывания сети (удаленный агент (URL https: // devserver02: 8172 / msdeploy.axd? site = Веб-сайт по умолчанию ). Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере.) Убедитесь, что имя сайта, имя пользователя и пароль верны. Если проблема не устранена, обратитесь к местному администратору или администратору сервера. Сведения об ошибке: Удаленный агент (URL https: // devserver02: 8172 / msdeploy.axd? Site = Веб-сайт по умолчанию ) не удалось связаться. Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере. Был получен неподдерживаемый ответ. Заголовок ответа ‘MSDeploy.Response’ был ”, но ожидалось ‘v1’. Удаленный сервер ответил на ошибку: (401) Неавторизованный.

    Это произошло потому, что имя пользователя и пароль, которые у меня были в / p: UserName = / p: Password =, не включали домен для пользователя. Несмотря на то, что assembly была запущена под этим пользователем, она не будет развертываться. Поэтому я ударил URL напрямую https: // devserver02: 8172 / msdeploy.axd в браузере, чтобы убедиться, что он работает, и убедитесь, что имя пользователя и пароль сработали. Здесь я заметил, что мне нужно было ввести домен / пользователя, чтобы он работал.

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

Если вы можете развернуть свои приложения с помощью fileCopy, легко настроить рабочий процесс TFS для этого.

Я использовал операцию CopyDirectory с помощью этих статей:

http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx

а также

http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx

Очень простой и понятный.

  • Я настроил службу построения с учетной записью пользователя, которая имеет права на запись на нужном ресурсе.

  • Затем я создал рабочий процесс CopyDirectory, настроив исходный код как BuildDetail.DropLocation + «_PublishedWebsites», и для адресата я создал аргумент, который я назвал «DeployPath», который можно заполнить в конфигурации сборки.

  • Теперь мне еще нужно выполнить тест, чтобы проверить, была ли assembly успешной, перед вызовом операции CopyDirectory. В статьях, которые я упоминал, показано, как это сделать. Они также учат, как вызывать скрипт powershell вместо CopyDirectory.

  • Asp.net 4.0 не зарегистрирован
  • Как использовать Visual Studio для проектов на C # вместо VB.NET?
  • 64-битные файлы в System32
  • Этот тип проекта не поддерживается этой установкой
  • Установка Visual Studio 2010 (любая версия) устанавливает только 2 файла в каталоге заголовков C ++
  • MVCBuildViews работают неправильно
  • Как использовать Boost в Visual Studio 2010
  • Тип или имя пространства имен «DbContext» не удалось найти
  • Одна ошибка VS2010? Разрешить привязку не-const ссылки на rvalue БЕЗ ДАЖЕ предупреждение?
  • Mercurial .hgignore для проектов Visual Studio 2010
  • Обновление пользовательского интерфейса в C # с использованием таймера
  • Давайте будем гением компьютера.