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

Question

Здесь можно найти отличное сообщение по 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) Unauthorized.

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

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

/p:MSDeployPublishMethod=WMSVC

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

Теперь он также пытается попасть по URL: https://your-web-server:8172/MsDeploy.axd <- это именно то, что делает окно Visual Studio 2010 <code>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

Заметили, что в имени пользователя есть доменное имя? Я нуждаюсь в этом, там. Кроме того, на моей картинке я разрешил нашим ДОМЕННЫМ ПОЛЬЗОВАТЕЛЯМ доступ к веб-сайту для управления. Таким образом, моя новая учетная запись пользователя (TFSBuildService) имеет членство в группе Domain Users ... вот как это все работает.

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

Answer 2

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

Тебе не обязательно делать так, но вот как я это заработал

• Настройка WMSVC
• Убедитесь, что служба запущена
• Настройте пользователя IIS (нажмите на TOP MOST SERVERNAME в IIS) и перейдите к «Пользователи IIS Manager». Я предлагаю сделать его отличным от вашего имени окна.
• Убедитесь, что учетная запись пользователя WMSVC (LOCAL SERVICE for me) имеет права на запись в каталог 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

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

Answer 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

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

---

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

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

Answer 4

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

/ р: MSDeployPublishMethod = RemoteAgent

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

/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MSDeployPublishMethod = RemoteAgent / p: MsDeployServiceUrl = http://my -server-name / p: имя пользователя = myusername / p: пароль = мой пароль

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

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

Answer 5

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

Answer 6

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

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 * 1021) * Веб-сайт) не удалось связаться. Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере.) Убедитесь, что имя сайта, имя пользователя и пароль указаны правильно. Если проблема не решена, пожалуйста, свяжитесь с вашим местным администратором или администратором сервера. Сведения об ошибке: не удалось связаться с удаленным агентом (URL https://devserver02:8172/msdeploy.axd?site=Default веб-сайт). Убедитесь, что служба удаленного агента установлена ​​и запущена на целевом компьютере. Неподдерживаемый ответ был получен. Заголовок ответа «MSDeploy.Response» был «», но ожидался «v1». Удаленный сервер возвратил ошибку: (401) Несанкционированный.

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

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

Answer 7

Для меня проблема была в том, что 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).

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

Answer 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 вместо CopyDirectory.