Як я можу отримати TFS2010 для запуску MSDEPLOY для мене через MSBUILD?

Існує відмінний 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-адреси користувач для автентифікації повинен бути адміністратором. Що обмануте. (І вам потрібно позначити правило перевизначення адміністратора). Ця адреса призначена для IIS6, я думаю.

Ось стандартне повідомлення про помилку при спробі підключитися за допомогою RemoteAgent: -

Стандартний 401 Frak вимкнено, смоктати 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 Service Manager. В основному це нова обгортка віддаленого агента, але тепер вона дозволяє нам виправляти ім’я користувача та пароль .. де користувач НЕ повинен бути адміністратором! (радість!) Тож тепер ви можете виправити встановлення, до яких користувачів ви хочете мати доступ .. на Веб-сайті ..

Тепер він також намагається натиснути URL-адресу: https://your-web-server:8172/MsDeploy.axd<- саме те, що Publishробить вікно Visual Studio 2010 ! (OMG -> ПЕННІ КРАПЛІ !! БУМ!)

І ось мої остаточні налаштування 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) ....

Ось кроки, які нарешті спрацювали для мене. Я хотів отримати роботу з RemoteAgent, але не зміг це зробити незалежно від того, що я намагався.

Вам не потрібно робити саме так, але я так змусив це працювати

• Налаштуйте WMSVC
• Переконайтеся, що послуга запущена
• Налаштуйте користувача IIS (натисніть НАЙБІЛЬШЕ НАЙБІЛЬШЕ ІМЯ СЕРВЕРА в IIS) і перейдіть до розділу "Користувачі IIS Manager". Я пропоную змінити його на назву вашого Windows.
• Переконайтеся, що обліковий запис користувача для WMSVC (ЛОКАЛЬНА СЛУЖБА для мене) має дозволи на запис у каталог 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 насправді є локальним вікном із записом файлу хостів, що вказує на 127.0.0.1. Localhost, мабуть, працював би і тут.

Корисні статті:

Вирішення проблем з MSDeploy

Більше усунення несправностей

На жаль, наразі про це немає багато інформації. У кінці цього повідомлення я дам вам кілька підказок.

Щодо вашої проблеми, я бачив це раніше, коли намагався розгорнути за допомогою 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

Тож для того, щоб зараз детально вивчити цю тему, вам слід перевірити ці файли та навчитися самостійно.

Я збираюся працювати над чимось, що буде детально висвітлювати ці технології, але це не з’явиться ще деякий час, і я ще маю багато чого розібратися в цьому.

Чи можете ви спробувати дію з ім’ям користувача / паролем і повідомити, чи це вам підходило?

У мене була подібна проблема, і рішенням було мати такий параметр:

/ 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, і всі три мої веб-програми успішно розгорнулися. Я помітив, що файл Package більше не міститься в папці 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. Обліковий запис, який я використовую для розгортання, - це службовий обліковий запис у домені, який має права адміністратора на обох машинах. Моє рішення включає пару проектів модульних тестів, проект 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: AllowUn / p: Allow = yourDomain \ buildaccount / p: Пароль = пароль

1. Елементом, з яким я боровся спочатку, були цитати навколо "Веб-сайт за замовчуванням / 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: Ім'я користувача = / p: Пароль = не включали домен для користувача. Незважаючи на те, що збірка працювала під цим користувачем, вона не розгорталася. Тому я натиснув 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", який можна заповнити у конфігурації збірки.

• Тепер я все ще маю впровадити тест, щоб перевірити, чи побудова була успішною, перш ніж викликати діяльність CopyDirectory. У згаданих статтях показано, як це зробити. Вони також вчать, як викликати сценарій PowerShell замість CopyDirectory.