Comment puis-je obtenir TFS2010 pour exécuter MSDEPLOY pour moi via MSBUILD?
Il y a un excellent PDC talk disponible ici de Vishal Joshi qui décrit les nouvelles fonctionnalités MSDEPLOY dans Visual Studio 2010 - ainsi que la façon de déployer une application dans TFS. ( Il y a aussi un excellent discours de Scott Hanselman mais il ne va pas dans TFS).
Vous pouvez utiliser MSBUILD dans TFS2010 pour appeler via MSDEPLOY pour déployer votre package sur IIS. Cela se fait au moyen de paramètres pour MSBUILD.
L'exposé explique certains des paramètres de ligne de commande tels que:
/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"
Mais où est la documentation pour cela - je n'en trouve pas?
J'ai passé toute la journée à essayer de faire fonctionner cela et je n'arrive pas à bien faire les choses et à me retrouver avec diverses erreurs. Si j'exécute le fichier cmd du package, il se déploie parfaitement. Si j'exécute WebDeploy via Visual Studio, cela fonctionne également parfaitement.
Mais je veux que tout le déploiement s'exécute via msbuild en utilisant ces arguments et non un appel distinct à msdeploy ou en exécutant le package .cmd fichier. Comment puis-je faire ceci?
PS. Oui, j'ai le Web Deployment Agent Service fonctionnement. J'ai également le service de gestion fonctionnant sous IIS. J'ai essayé d'utiliser les deux.
Args que j'utilise:
/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
me donnant :
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy a échoué. (Agent distant (URL https: // transfert). example.com:8172/msdeploy.axd?site=staging.example.com ) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible.) Détail de l'erreur: Agent distant (URL - https://staging.example.com:8172/msdeploy.axd?site=staging.example.com ) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible. Une réponse non prise en charge a été reçue. L'en-tête de réponse "MSDeploy.Response" était "" mais "v1" était attendu. Le serveur distant a renvoyé une erreur: (401) Non autorisé.
Réponse relative à IIS7 + ....
Ok - voici ce que j'ai fini par faire. Plus ou moins, en suivant le post de Simon Weaver dans ce fil/question.
Mais en ce qui concerne les paramètres MSBuild .. la plupart des gens ici utilisent le paramètre suivant: /p:MSDeployPublishMethod=RemoteAgent qui est PAS DROIT pour IIS7. L'utilisation de ce paramètre signifie que TFS essaie de se connecter à l'url: https://your-server-name/MSDEPLOYAGENTSERVICE Mais pour accéder à cette URL, l'utilisateur à authentifier doit être un administrateur. Ce qui est effrayé. (Et vous devez cocher la règle Admin-override). Cette URL est pour IIS6 je pense.
Voici le message d'erreur standard lorsque vous essayez de vous connecter à l'aide de RemoteAgent: -
Standard 401 Frak Off u suck RemoteAgent, erreur
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): la tâche de déploiement Web a échoué. (Agent distant (URL http: // your-web-server/MSDEPLOYAGENTSERVICE ) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible.) Assurez-vous que le nom du site, le nom d'utilisateur et le mot de passe sont corrects. Si le problème n'est pas résolu, veuillez contacter votre administrateur local ou serveur. Détails de l'erreur: l'agent distant (URL http: // votre-serveur-web/MSDEPLOYAGENTSERVICE ) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible. Une réponse non prise en charge a été reçue. L'en-tête de réponse "MSDeploy.Response" était "V1" mais "v1" était attendu. Le serveur distant a renvoyé une erreur: (401) Non autorisé.
Donc .. vous devez changer votre MSDeployPublishMethod en ceci:
/p:MSDeployPublishMethod=WMSVC
WMSVC signifie Windows Manager Service. Il s'agit essentiellement d'un wrapper plus récent sur l'agent distant, mais nous permet maintenant de corriger fournir un nom d'utilisateur et un mot de passe .. où l'utilisateur n'a PAS besoin d'être un administrateur! (joie!) Alors maintenant, vous pouvez corriger définir les utilisateurs auxquels vous voulez avoir accès .. par site Web ..
Il essaie également maintenant d'appuyer sur l'url: https://your-web-server:8172/MsDeploy.axd <- ce qui est EXACTEMENT ce que fait la fenêtre Visual Studio 2010 Publish! (OMG -> PENNY DROPS !! BOOM!)
Et voici mes derniers paramètres 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
Remarquez que le nom d'utilisateur contient le nom de domaine? Tu en as besoin, là. De plus, sur ma photo, j'ai autorisé nos UTILISATEURS DE DOMAINE à accéder au site Web pour la gestion. En tant que tel, mon nouveau compte utilisateur que j'ai ajouté (TFSBuildService) est membre de Domain Users groupe ... c'est comme ça que tout fonctionne.
Maintenant - si vous avez lu tout cela, prenez un lolcat (car ils sont SOOOOOOOO 2007) ....
Voici les étapes qui ont finalement fonctionné pour moi. Je voulais faire fonctionner RemoteAgent, mais je ne pouvais pas le faire fonctionner, quoi que j'aie essayé.
Vous n'avez pas à faire exactement comme ça, mais c'est comme ça que je l'ai fait fonctionner
- Configurer WMSVC
- Assurez-vous que le service est démarré
- Configurez un IIS utilisateur (cliquez sur le TOP NOM DU SERVEUR dans IIS) et allez dans 'IIS Manager Users'. Je suggère de le rendre différent de votre nom Windows.
- Assurez-vous que le compte d'utilisateur pour WMSVC (SERVICE LOCAL pour moi) dispose d'autorisations d'écriture dans le répertoire IIS que vous utilisez
- Dans mon cas, j'utilise un certificat SSL (même s'il frappe localhost).
N'oubliez pas que ce sont tous des arguments pour MSBUILD ajoutés dans la définition de build 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
Remarque: staging.example.com est en fait la boîte locale avec une entrée fichier hôte pointant vers 127.0.0.1. Localhost fonctionnerait probablement ici aussi.
Articles utiles:
Malheureusement, il n'y a pas beaucoup d'informations à ce sujet pour le moment. Je vais cependant vous donner quelques conseils à la fin de ce message.
À propos de votre problème, je l'ai déjà vu lorsque j'essayais de déployer à l'aide de MSDeploy et que le compte sur lequel j'exécutais n'avait pas les autorisations pour exécuter le déploiement sur la machine cible. Vous devez donc examiner le compte sous lequel vos versions s'exécutent et voir si ce compte a les droits de déploiement sur la machine cible. Sinon, vous avez quelques options; accordez les droits à l'utilisateur de la version ou transmettez le nom d'utilisateur/mot de passe.
Si vous souhaitez transmettre les valeurs, vous devrez définir un élément nommé MsDeployDestinationProviderSetting et ses métadonnées devront contenir les valeurs nécessaires.
Donc, dans votre fichier de projet (ou via les propriétés transmises), définissez quelque chose comme ceci.
<PropertyGroup>
<UserName>USERNAME-HERE</UserName>
<Password>PASSWORD-HERE
</PropertyGroup>
Où pouvez-vous trouver de la documentation, comme je l'ai déjà dit, il n'y a pas encore grand-chose. Mais comme l'ensemble du pipeline de publication Web est capturé dans des cibles et des tâches MSBuild, vous pouvez en apprendre beaucoup par vous-même si vous connaissez MSBuild. Si vous examinez les fichiers .csproj (ou .vbproj) pour les projets Web créés avec Visual Studio 2010, vous remarquerez une déclaration comme celle-ci:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Cela importe le fichier situé dans %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, et ce fichier à son tour importe %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Donc, pour apprendre ce sujet en détail en ce moment, vous devez inspecter ces fichiers et apprendre par vous-même.
Je vais travailler sur quelque chose qui couvrira ces technologies en détail, mais cela ne sera pas disponible avant un bon moment, et j'ai encore beaucoup de choses à comprendre sur ce sujet.
Pouvez-vous essayer l'offre de nom d'utilisateur/mot de passe et faites-moi savoir si cela a fonctionné pour vous?
J'ai eu un problème similaire et la solution était d'avoir le paramètre suivant:
/ p: MSDeployPublishMethod = RemoteAgent
Voici tous les paramètres que j'ai utilisés.
/ p: DeployOnBuild = True/p: DeployTarget = MSDeployPublish/p: MSDeployPublishMethod = RemoteAgent /p: MsDeployServiceUrl = http: // my -server-name /p: username = myusername/p: password = mypassword
REMARQUE: je n'utilise pas DeployIisAppPath car je crée une solution et j'essaie de créer trois applications Web à la fois. Je pense également que votre MsDeployServiceUrl devrait être juste http://staging.example.com
Il semble que lorsque vous utilisez InProc (qui peut être la valeur par défaut) pour MSDeployPublishMethod, MSBuild ignore MsDeployServiceUrl et essaie toujours de se déployer sur le serveur local. Je l'ai changé en RemoteAgent et mes trois applications Web ont été déployées avec succès. J'ai remarqué que le fichier de package n'est plus contenu dans le dossier MyWebApplication_Package, mais ce n'est pas un gros problème pour moi.
Notez que vous pouvez également définir DeployTarget = Package - cela préparera le package mais ne le déploiera pas immédiatement. Pour plus d'informations, voir cet article de blog .
Pour moi, le problème était que Web Deployment Agent Service n'a pas été démarré.
Un simple net start msdepsvc l'a corrigé. Vous pouvez également définir le mode de démarrage sur Automatique sur ce service.
Les arguments que j'utilise sont:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MSDeployServiceUrl=stagingserver
/p:DeployIisAppPath=test.local
/p:UserName=
Il vous suffit de spécifier le nom du serveur, et non le chemin complet (pas de http nécessaire).
Notez que UserName est laissé vide pour contourner un bogue avec l'authentification NTLM (de cette façon, il utilise les informations d'identification de l'agent de génération TFS pour le déploiement). voir la réponse acceptée ici
Voici comment je l'ai fait fonctionner. C'était avec Webdeploy 2.0. Je déploie sur le même domaine à partir de notre machine de génération vers un serveur Windows 2008 de machine de serveur Web dev R2. Le compte que j'utilise pour déployer est un compte de service sur le domaine qui dispose des autorisations d'administrateur sur les deux machines. Ma solution comprend quelques projets de tests unitaires, un projet mvc3 et quelques bibliothèques sous la solution. Si vous n'installez pas MVC3 sur le serveur que vous déployez pour consulter http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio pour des conseils.
/ p: DeployOnBuild = True/p: DeployTarget = MSDeployPublish/p: DeployIisAppPath = "Site Web par défaut/YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd/p: AllowUntrustedCertificate = votreDomaine\buildaccount/p: Mot de passe = mot de passe
L'élément avec lequel j'ai eu du mal au début était les citations autour de "Site Web par défaut/YourpplicationNameHere" qui donne l'erreur partielle:
MSBUILD: erreur MSB1008: un seul projet peut être spécifié.
Cela se produit lorsqu'il n'y a pas de guillemets autour du site Web par défaut/YourApplicationNameHere
L'erreur suivante que j'ai obtenue était due au nom d'utilisateur et au mot de passe incorrects dans mes informations d'identification pour le déploiement. Il a donné cette erreur:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): la tâche de déploiement Web a échoué. (Agent distant (URL https: // devserver02: 8172/msdeploy.axd? site = Default Site Web) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible.) Assurez-vous que le nom du site, le nom d'utilisateur et le mot de passe sont correct. Si le problème n'est pas résolu, veuillez contacter votre administrateur local ou serveur. Détails de l'erreur: l'agent distant (URL https: // devserver02: 8172/msdeploy.axd? Site = Par défaut Site Web) n'a pas pu être contacté. Assurez-vous que le service d'agent distant est installé et démarré sur l'ordinateur cible. Une réponse non prise en charge a été reçue. L'en-tête de réponse "MSDeploy.Response" était "" mais "v1" était attendu. Le serveur distant a renvoyé une erreur: (401) Non autorisé.
En effet, le nom d'utilisateur et le mot de passe que j'avais dans/p: UserName =/p: Password = n'incluaient pas le domaine de l'utilisateur. Même si la version s'exécutait sous cet utilisateur, elle ne serait pas déployée. J'ai donc frappé l'url directement https: // devserver02: 8172/msdeploy.axd dans un navigateur pour m'assurer qu'il fonctionnait et que le nom d'utilisateur et le mot de passe fonctionnaient. C'est là que j'ai remarqué que je devais mettre le domaine/utilisateur pour le faire fonctionner.
J'espère que c'est OK pour répondre J'ai pensé à une autre pauvre âme avec trouver ces erreurs et cela pourrait aider ...
Si vous pouvez déployer vos applications avec fileCopy, il est facile de personnaliser le flux de travail TFS pour ce faire.
J'ai utilisé l'activité CopyDirectory, à l'aide de ces articles:
http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx
et
Très simple et direct.
J'ai configuré le service de génération avec un compte d'utilisateur disposant de privilèges d'écriture sur le partage souhaité.
Ensuite, j'ai créé l'étape du flux de travail CopyDirectory, configurant la source en tant que BuildDetail.DropLocation + "_PublishedWebsites" et pour la destination j'ai créé un argument, que j'ai appelé "DeployPath", qui peut être rempli dans la configuration de construction.
Maintenant, je dois encore implémenter un test pour vérifier si la génération a réussi avant d'appeler l'activité CopyDirectory. Les articles que j'ai mentionnés montrent comment procéder. Ils enseignent également comment invoquer un script PowerShell au lieu de CopyDirectory.