Comment puis-je obtenir TFS2010 à courir MSDEPLOY pour moi par MSBUILD?
https://stackoverflow.com/questions/2636153
-
26-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Il y a un excellent talk PDC ici de Vishal Joshi qui décrit la nouvelle MSDEPLOY fonctionnalités de Visual studio 2010 - ainsi que la façon de déployer une application au sein de TFS. (Il y a aussi un grand discours de Scott Hanselman mais il ne va pas dans TFS).
Vous pouvez utiliser MSBUILD au sein TFS2010 appeler jusqu'à MSDEPLOY pour déployer votre package à IIS. Cela se fait au moyen de paramètres à MSBUILD.
Le discours 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 de ce - je ne trouve pas de
J'ai passé toute la journée à essayer d'obtenir ce travail à et ne peut pas tout à fait le faire à droite et continuer de se retrouver avec diverses erreurs. Si je lance le fichier cmd du paquet, il déploie parfaitement. Si je lance WebDeploy par Visual Studio fonctionne également parfaitement.
Mais je veux tout le déploiement en cours d'exécution à travers msbuild en utilisant ces arguments, et non un appel séparé pour msdeploy ou exécutant le fichier .cmd du package. Comment puis-je faire?
PS. Oui, je n'ai le fonctionnement de Web Deployment Agent Service. J'ai aussi le service de gestion en cours d'exécution sous IIS. Je l'ai essayé d'utiliser les deux.
args 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 donner:
C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (2660):. VsMsdeploy a échoué (agent à distance (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 à distance est installé et démarré sur l'ordinateur cible) détail d'erreur:.. Remote Agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com ) ne pouvait pas être contacté. Assurez-vous que le service d'agent à distance 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ée
La solution
IIS7 + réponse connexe ....
Ok - voici ce que je fini par faire. Plus ou moins, après le poste par Simon Weaver dans ce fil / question.
Mais en ce qui concerne les réglages de MSBuild .. la plupart des gens utilisent en paramètre suivant: /p:MSDeployPublishMethod=RemoteAgent qui est PAS DROIT pour IIS7. L'utilisation de ce moyen de réglage TFS tente de se connecter à l'URL: https://your-server-name/MSDEPLOYAGENTSERVICE Mais pour accéder à l'URL, l'utilisateur aux besoins authentifient être administrateur. Ce qui est fraked. (Et vous devez avoir la règle Admin-override thingy cochée). Cette URL est pour IIS6 je pense.
Voici le message d'erreur standard lorsque vous essayez de vous connecter en utilisant RemoteAgent: -
Standard 401 Frak Off u sucent RemoteAgent, erreur
C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588): tâche de déploiement Web a échoué. (agent à distance (URL http: // votre-serveur web / MSDEPLOYAGENTSERVICE ) n'a pas pu être contacté. Assurez-vous que la service d'agent à distance est installé et a commencé sur l'ordinateur cible.) Faire que le nom du site, le nom d'utilisateur et mot de passe sont corrects. Si le problème est pas résolu, s'il vous plaît contacter votre administrateur local ou d'un serveur. Erreur détails: Remote Agent (URL http: // votre-serveur web / MSDEPLOYAGENTSERVICE ) n'a pas pu être contacté. Assurez-vous que la service d'agent à distance est installé et a commencé sur l'ordinateur cible. Un réponse non pris en charge a été reçue. le tête de réponse « MSDeploy.Response » a été « V1 », mais « v1 » était attendu. le serveur distant a renvoyé une erreur: (401) Non autorisé.
.. vous devez changer votre MSDeployPublishMethod à ceci:
/p:MSDeployPublishMethod=WMSVC
Le WMSVC signifie Gestionnaire de services Windows. Il est essentiellement un emballage plus récente sur Remote Agent mais nous permet maintenant de corriger fournir un nom d'utilisateur et mot de passe .. où l'utilisateur ne doit pas être un admin! (Joie!) Alors maintenant, vous pouvez corriger ensemble que les utilisateurs veulent u d'avoir accès à .. .. par WebSite
Il essaie désormais de frapper l'url: https://your-web-server:8172/MsDeploy.axd <- qui est exactement ce que la fenêtre Publish Visual Studio 2010 ne! (OMG -> PENNY DROPS !! BOOM)
Et voici mes derniers réglages de 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
Notez que le nom d'utilisateur est le nom de domaine en elle? Ya besoin que, là-bas. En outre, dans ma photo, je l'ai permis à nos utilisateurs du domaine accès au site pour managament. En tant que tel, mon nouveau compte utilisateur i ajouté (TFSBuildService) a adhésion au groupe Domain Users ... Voilà donc comment tout cela fonctionne.
- si u've lu tout cela, un lolcat (car ils sont soooooooo 2007) ....
Autres conseils
Voici les étapes qui ont finalement travaillé pour moi. Je voulais obtenir le travail avec RemoteAgent, mais n'a pas pu obtenir que le travail, peu importe ce que j'ai essayé.
Vous n'avez pas à ce faire exactement comme, mais voilà comment je l'ai eu de travail
- Configurer WMSVC
- Assurez-vous que le service est démarré
- Configurer un utilisateur IIS (cliquez sur le plus haut sommet SERVERNAME dans IIS) et allez à 'utilisateurs Gestionnaire des services Internet. Je suggère ce qui rend différent de votre nom de Windows.
- Assurez-vous que le compte utilisateur pour WMSVC (SERVICE LOCAL pour moi) dispose des autorisations d'écriture sur le répertoire IIS que vous utilisez
- Dans mon cas, j'utilise un certificat SSL (même si elle frappe localhost).
Rappelez-vous ce sont tous les arguments à 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
Note: staging.example.com est en fait la boîte locale avec une entrée de fichier hôtes pointage à 127.0.0.1. Localhost fonctionnerait probablement ici aussi.
articles utiles:
Malheureusement, il n'y a pas beaucoup d'informations sur ce sujet à ce moment. Je vais vous donner quelques conseils à la fin de ce message si.
A propos de votre problème, je l'ai vu ceci avant quand je tentais de déployer à l'aide MSDeploy et le compte que je courais sur ne pas les autorisations nécessaires pour effectuer le déploiement sur la machine cible. Donc, vous devez jeter un oeil sur le compte que vos constructions sont en cours d'exécution sous et voir si ce compte a le droit de déployer sur la machine cible. Sinon, vous avez quelques options; accorder à l'utilisateur de construire les droits, ou de transmettre le nom d'utilisateur / mot de passe.
Si vous voulez passer les valeurs alors vous devrez définir un élément nommé MsDeployDestinationProviderSetting et ses métadonnées devra contenir les valeurs nécessaires.
dans votre fichier de projet (ou via les propriétés passées en) définir quelque chose comme ce qui suit.
<PropertyGroup>
<UserName>USERNAME-HERE</UserName>
<Password>PASSWORD-HERE
</PropertyGroup>
A propos où trouver la documentation, comme je l'ai dit avant qu'il n'y ait pas grand-chose là-bas encore. Mais depuis toute publication Web Pipeline est capturé dans les cibles MSBuild et les tâches que vous pouvez apprendre beaucoup sur vous-même si vous êtes familier avec MSBuild. Si vous jetez un oeil à la .csproj (ou .vbproj) fichiers pour les projets Web créés avec Visual Studio 2010, vous remarquerez une déclaration comme suit:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
Ce importe le fichier situé à
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, et ce fichier dans les importations tour
%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Ainsi, afin d'apprendre sur ce sujet en détail en ce moment, vous devez vérifier ces fichiers et d'apprendre par vous-même.
Je vais travailler sur quelque chose qui couvrira ces technologies en détail, mais ce ne sera pas pour un certain temps, et j'ai encore beaucoup à comprendre moi-même au sujet de ce genre de choses.
Pouvez-vous essayer le nom d'utilisateur / mot de passe et beaucoup me faire savoir si elle a travaillé 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é.
/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: MSDeployPublishMethod = RemoteAgent / p: MsDeployServiceUrl = http: // my-server-name / p: nom d'utilisateur = myusername / p: password = motdepasse
NOTE: Je ne suis pas en utilisant DeployIisAppPath parce que je suis la construction d'une solution et d'essayer de construire trois applications Web à la fois. Aussi je pense que votre MsDeployServiceUrl devrait être juste http://staging.example.com
Il semble que lors de l'utilisation InProc (qui peut être la valeur par défaut) pour le MSDeployPublishMethod MSBuild ignore MsDeployServiceUrl et essaie toujours de déployer sur le serveur local. Je l'ai changé pour RemoteAgent et trois de mes applications Web déployées avec succès. J'ai remarqué que le fichier de package est nolonger 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 paquet mais pas déployer tout de suite. Pour voir plus d'info ce billet de blog .
Pour moi, le problème était que Web Deployment Agent Service n'a pas démarré.
Une net start msdepsvc de simple, il fixe. Vous pouvez également définir le mode de démarrage automatique pour ce service.
Les arguments que je utilise sont:
/p:DeployOnBuild=True
/p:DeployTarget=MsDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MSDeployServiceUrl=stagingserver
/p:DeployIisAppPath=test.local
/p:UserName=
Vous ne devez spécifier le nom du serveur, et non le chemin complet (pas http nécessaire).
Notez que UserName est laissé vide pour travailler autour d'un bug avec l'authentification NTLM (cette façon dont il utilise les informations d'identification de l'agent de build TFS pour le déploiement). voir la réponse acceptée
Voici comment je l'ai eu au travail. Ce fut avec Webdeploy 2.0. Je suis sur le même déployez domaine de notre machine à construire une machine windows serveur web dev Server 2008 R2. Le compte que je me sers de déployer est un compte de service sur le domaine qui dispose des autorisations d'administrateur sur les deux machines. Ma solution comprend deux projets de tests unitaires, un projet MVC3, et deux bibliothèques dans la solution. Si vous n'installez pas MVC3 sur le serveur que vous déployez à regarder http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio à titre indicatif.
/ p: DeployOnBuild = True / p: DeployTarget = MSDeployPublish / p: DeployIisAppPath = "Default Web Site / YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd / p: AllowUntrustedCertificate = Vrai / p: UserName = yourDomain \ buildaccount / p: Mot de passe = mot de passe
-
L'article que je débattais avec d'abord étaient les guillemets autour de « Default Web Site / YourpplicationNameHere » Cela donne l'erreur partielle:
MSBUILD: erreur MSB1008:. Un seul projet peut être spécifié
Cela arrive quand il n'y a pas de guillemets par défaut autour du site Web / YourApplicationNameHere
-
La prochaine erreur que je suis arrivé était à cause du mauvais nom d'utilisateur et mot de passe dans mes lettres de créance pour le déploiement. Il a donné cette erreur:
C: \ Program Files (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets (3588):. Tâche de déploiement Web a échoué (agent distant (URL https: // devserver02:. 8172 / msdeploy.axd site = défaut du site Web) n'a pas pu être contacté Marque que le service d'agent à distance est installé et démarré sur l'ordinateur cible.) Assurez-vous que le nom du site, le nom d'utilisateur et mot de passe sont corrects. Si le problème persiste, s'il vous plaît contacter votre administrateur local ou d'un serveur. Détails de l'erreur: 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 à distance 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ée
En effet, le nom d'utilisateur et mot de passe que j'avais dans / p: UserName = / p: Mot de passe = ne comprennent pas le domaine pour l'utilisateur. Même si elle la construction est en cours d'exécution sous cet utilisateur ne pas se déployer. Alors je frappe directement l'URL https: // devserver02: 8172 / msdeploy.axd dans un navigateur pour vous assurer il a été l'opération et assurez-vous que le nom d'utilisateur et mot de passe travaillé. C'est là que je remarqué que je devais mettre dans le domaine / utilisateur pour l'obtenir au travail.
J'espère que c'est OK pour répondre je me suis dit un autre pauvre âme trouver ces erreurs et cela pourrait aider ...
Si vous pouvez déployer vos applications avec FILECOPY, il est facile de personnaliser les flux de travail TFS pour le faire.
Je l'ai utilisé l'activité CopyDirectory, avec 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.
-
Je Configuré le service de construction avec un compte d'utilisateur disposant de droits d'écriture sur la part souhaitée.
-
Ensuite, j'ai créé l'étape du workflow de CopyDirectory, configuration de la source comme BuildDetail.DropLocation + « _PublishedWebsites » et pour la destination que j'ai créé un argument, que j'ai appelé « DeployPath », qui peut être rempli dans la configuration de construction .
-
Maintenant, je dois encore mettre en place un test pour vérifier si la construction a réussi avant d'invoquer l'activité CopyDirectory. Les articles que j'ai mentionnés montrent comment faire. Ils enseignent aussi comment appeler un script Powershell au lieu de CopyDirectory.
