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

Ответ 1

Ответ, связанный с 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-server/MSDEPLOYAGENTSERVICE) не удалось связаться. Убедитесь, что служба удаленного агента установлена ​​и запущен на целевом компьютере.) Сделайте убедитесь, что имя сайта, имя пользователя и пароль правильный. Если проблема не разрешены, пожалуйста, свяжитесь с вашим локальный или серверный администратор. ошибка подробности: Удаленный агент (URL http://your-web-server/MSDEPLOYAGENTSERVICE) не удалось связаться. Убедитесь, что служба удаленного агента установлена ​​и начался на целевом компьютере. был получен неподдерживаемый ответ. ответный заголовок 'MSDeploy.Response' был "V1", но ожидалось "v1". удаленный сервер возвратил ошибку: (401) Несанкционированное.

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

/p:MSDeployPublishMethod=WMSVC

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

Теперь он также пытается ударить по URL: https://your-web-server:8172/MsDeploy.axd < - что ТОЧНО, что делает окно Visual Studio 2010 Publish! (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)....

Ответ 2

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

Вам не нужно делать именно так, но я так понял, что работал

• Настроить WMSVC
• Убедитесь, что служба запущена.
• Настройте пользователя IIS (нажмите "TOP MOST SERVERNAME" в IIS) и перейдите к "Диспетчеру IIS". Я предлагаю сделать это иначе, чем имя вашего окна.
• Убедитесь, что учетная запись пользователя 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 file, указывающей на 127.0.0.1. Localhost, вероятно, тоже будет работать здесь.

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

Устранение проблем MSDeploy

Другие способы устранения неполадок

Ответ 3

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

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

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

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

<PropertyGroup>
    <UserName>USERNAME-HERE</UserName>
    <Password>PASSWORD-HERE
</PropertyGroup>

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

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

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

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

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

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

Ответ 4

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

/р: 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, но для меня это не очень важно.

Ответ 5

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

Ответ 6

Для меня проблема заключалась в том, что 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 для развертывания). см. принятый ответ здесь

Ответ 7

Вот как я заработал. Это было с Webdeploy 2.0. Я развертываю в том же домене с нашей машины для сборки на сервере Windows Server 2008 r2 сервера веб-сервера dev. Учетная запись, которую я использую для развертывания, - это учетная запись службы в домене с правами администратора на обеих машинах. Мое решение включает в себя пару проектов unit test, проект 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: Пароль = пароль

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

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

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

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

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

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

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

Ответ 8

Если вы можете развернуть свои приложения с помощью 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", который может быть заполнен в конфигурации сборки.

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