web-dev-qa-db-de.com

Wie kann ich TFS2010 dazu bringen, MSDEPLOY für mich über MSBUILD auszuführen?

Es gibt eine exzellente PDC talk hier verfügbar von Vishal Joshi, die die neuen MSDEPLOY-Funktionen in Visual Studio 2010 beschreibt - sowie wie eine Anwendung in TFS bereitgestellt wird. ( Es gibt auch ein großartiges Gespräch von Scott Hanselman, aber er geht nicht auf TFS ein).

Sie können MSBUILD in TFS2010 verwenden, um MSDEPLOY aufzurufen und Ihr Paket für IIS bereitzustellen. Dies erfolgt über Parameter zu MSBUILD.

Der Vortrag erklärt einige der Befehlszeilenparameter wie:

/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"

Aber wo ist die Dokumentation dafür - ich kann keine finden?

Ich habe den ganzen Tag damit verbracht, dies zum Laufen zu bringen und kann es nicht ganz richtig machen und endete immer wieder mit verschiedenen Fehlern. Wenn ich die cmd -Datei des Pakets ausführe, wird es perfekt bereitgestellt. Wenn ich WebDeploy über Visual Studio ausführe, funktioniert es auch einwandfrei.

Ich möchte jedoch, dass die gesamte Bereitstellung mit diesen Argumenten durch msbuild und nicht durch einen separaten Aufruf von msdeploy oder durch Ausführen der Paketdatei .cmd Ausgeführt wird. Wie kann ich das machen?

PS. Ja, ich habe den Web Deployment Agent Service Ausgeführt. Ich habe auch den Verwaltungsdienst unter IIS ausgeführt. Ich habe versucht, beide zu verwenden.


Argumente, die ich benutze:

/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

gibt mir :

C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy ist fehlgeschlagen. (Remote-Agent (URL https: // Staging). example.com:8172/msdeploy.axd?site=staging.example.com ) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist.) Fehlerdetails: Remote-Agent (URL - https://staging.example.com:8172/msdeploy.axd?site=staging.example.com ) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist. Eine nicht unterstützte Antwort wurde empfangen. Der Antwortheader 'MSDeploy.Response' war '', aber 'v1' wurde erwartet. Der Remote-Server hat einen Fehler zurückgegeben: (401) Nicht autorisiert.

78
Simon_Weaver

IIS7 + bezogene Antwort ....

Ok - hier ist, was ich getan habe. Mehr oder weniger nach dem Beitrag von Simon Weaver in diesem Thread/Frage.

Aber wenn es um die MSBuild-Einstellungen geht, verwenden die meisten Leute hier die folgenden Einstellungen: /p:MSDeployPublishMethod=RemoteAgent NICHT RICHTIG für IIS7. Wenn Sie diese Einstellung verwenden, versucht TFS, eine Verbindung zur folgenden URL herzustellen: https://your-server-name/MSDEPLOYAGENTSERVICE Um auf diese URL zugreifen zu können, muss der zu authentifizierende Benutzer ein Administrator sein. Welches ist fraked. (Und Sie müssen das Häkchen bei der Admin-Override-Regel setzen). Diese URL ist für IIS6, denke ich.

Hier ist die Standardfehlermeldung, wenn Sie versuchen, eine Verbindung mit RemoteAgent herzustellen:

Standard 401 Frak Off u saugen RemoteAgent, Fehler

C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): Webbereitstellungstask fehlgeschlagen. (Remote-Agent (URL http: // Ihr-Webserver/MSDEPLOYAGENTSERVICE ) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist.) Stellen Sie sicher, dass der Site-Name, der Benutzername und das Kennwort korrekt sind. Wenn das Problem nicht behoben ist, wenden Sie sich an Ihren lokalen Administrator oder Serveradministrator. Fehlerdetails: Der Remote-Agent (URL http: // Ihr-Webserver/MSDEPLOYAGENTSERVICE ) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist. Eine nicht unterstützte Antwort wurde empfangen. Der Antwortheader 'MSDeploy.Response' war 'V1', aber 'v1' wurde erwartet. Der Remote-Server hat einen Fehler zurückgegeben: (401) Nicht autorisiert.

Also .. Sie müssen Ihr MSDeployPublishMethod folgendermaßen ändern:

/p:MSDeployPublishMethod=WMSVC

Das WMSVC steht für Windows Manager Service. Es handelt sich im Grunde genommen um einen neueren Wrapper für den Remote Agent, der es uns jedoch jetzt ermöglicht, einen Benutzernamen und ein Kennwort korrekt anzugeben. Dabei muss der Benutzer KEIN Administrator sein! (Freude!) So, jetzt kannst du korrigieren, auf welche Benutzer du Zugriff haben willst .. per WebSite ..

enter image description here

Es wird nun auch versucht die URL zu treffen: https://your-web-server:8172/MsDeploy.axd <- genau das macht das Visual Studio 2010 Publish Fenster! (OMG -> PENNY DROPS !! BOOM!)

enter image description here

Und hier sind meine letzten MSBuild-Einstellungen:

/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

Beachten Sie, dass der Benutzername den Domainnamen enthält? Das brauchst du dort. Außerdem habe ich in meinem Bild unseren DOMAIN-BENUTZERN Zugriff auf die Website zur Verwaltung gewährt. Daher hat mein neues Benutzerkonto, das ich hinzugefügt habe (TFSBuildService), die Mitgliedschaft bei Domain Users group ... so funktioniert das also.

Nun - wenn Sie all das gelesen haben, haben Sie einen Lolcat (weil sie SOOOOOOOO 2007 sind) ....

enter image description here

48
Pure.Krome

Hier sind die Schritte, die endlich bei mir geklappt haben. Ich wollte mit RemoteAgent arbeiten, aber ich konnte das nicht zum Laufen bringen, egal was ich versuchte.

Du musst das nicht genau so machen, aber so habe ich es geschafft

  • WMSVC konfigurieren
  • Stellen Sie sicher, dass der Dienst gestartet ist
  • Konfigurieren Sie einen IIS Benutzer (klicken Sie auf den HÖCHSTEN SERVERNAMEN in IIS) und gehen Sie zu "IIS-Manager-Benutzer".
  • Stellen Sie sicher, dass das Benutzerkonto für WMSVC (für mich LOKALER DIENST) Schreibberechtigungen für das von Ihnen verwendete Verzeichnis IIS=) hat
  • In meinem Fall verwende ich ein SSL-Zertifikat (obwohl es localhost betrifft).

Denken Sie daran, dass dies alles Argumente für MSBUILD sind, die in der TFS-Build-Definition hinzugefügt wurden

/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

Hinweis: staging.example.com ist eigentlich die lokale Box mit einem hosts-Datei -Eintrag, der auf 127.0.0.1 zeigt. Localhost würde wahrscheinlich auch hier funktionieren.

Nützliche Artikel:

Problembehandlung bei MSDeploy-Problemen

Weitere Fehlerbehebung

19
Simon_Weaver

Leider gibt es zu diesem Zeitpunkt noch nicht viele Informationen. Ich gebe Ihnen jedoch am Ende dieser Nachricht einige Hinweise.


Was Ihr Problem betrifft, habe ich dies bereits bei dem Versuch gesehen, mit MSDeploy bereitzustellen, und das Konto, unter dem ich ausgeführt wurde, verfügte nicht über die Berechtigungen zum Ausführen der Bereitstellung auf dem Zielcomputer. Sie müssen sich also das Konto ansehen, unter dem Ihre Builds ausgeführt werden, und prüfen, ob dieses Konto über die Berechtigungen zum Bereitstellen auf dem Zielcomputer verfügt. Wenn nicht, haben Sie einige Möglichkeiten. Gewähren Sie dem Build-Benutzer die Rechte oder geben Sie den Benutzernamen/das Passwort ein.

Wenn Sie die Werte übergeben möchten, müssen Sie ein Element mit dem Namen MsDeployDestinationProviderSetting definieren und dessen Metadaten müssen die erforderlichen Werte enthalten.

Definieren Sie daher in Ihrer Projektdatei (oder über die übergebenen Eigenschaften) Folgendes.

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

Über wo finden Sie Dokumentation, wie ich bereits sagte, gibt es noch nicht viel da draußen. Da jedoch die gesamte Web Publishing-Pipeline in MSBuild-Zielen und -Aufgaben erfasst wird, können Sie viel selbst lernen, wenn Sie mit MSBuild vertraut sind. Wenn Sie sich die .csproj- (oder .vbproj-) Dateien für Webprojekte ansehen, die mit Visual Studio 2010 erstellt wurden, werden Sie eine Aussage wie die folgende bemerken:

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

Dadurch wird die Datei importiert, die sich unter %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets befindet, und diese Datei importiert wiederum %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets.

Um dieses Thema jetzt im Detail zu lernen, müssen Sie diese Dateien überprüfen und selbst lernen.


Ich werde an etwas arbeiten, das diese Technologien im Detail abdeckt, aber es wird noch eine Weile dauern, und ich muss noch viel über dieses Zeug herausfinden.

Können Sie den Benutzernamen-/Passwort-Deal ausprobieren und mich wissen lassen, ob er für Sie funktioniert hat?

16

Ich hatte ein ähnliches Problem und die Lösung bestand darin, den folgenden Parameter zu haben:

/ p: MSDeployPublishMethod = RemoteAgent

Hier sind alle Parameter, die ich verwendet habe.

/ p: DeployOnBuild = True/p: DeployTarget = MSDeployPublish/p: MSDeployPublishMethod = RemoteAgent /p: MsDeployServiceUrl = http: // my -server-name /p: benutzername = meinbenutzername/p: kennwort = meinkennwort

ANMERKUNG: Ich verwende DeployIisAppPath nicht, weil ich eine Lösung erstelle und versuche, drei Webanwendungen gleichzeitig zu erstellen. Ich denke auch, dass Ihre MsDeployServiceUrl einfach http://staging.example.com sein sollte

Bei Verwendung von InProc (möglicherweise der Standardwert) für die MSDeployPublishMethod ignoriert MSBuild anscheinend MsDeployServiceUrl und versucht immer, die Bereitstellung auf dem lokalen Server durchzuführen. Ich habe es in RemoteAgent geändert und alle drei meiner Webanwendungen erfolgreich implementiert. Ich habe festgestellt, dass die Paketdatei nicht mehr im Ordner MyWebApplication_Package enthalten ist, aber das ist für mich keine große Sache.

6
Chad Peck

Beachten Sie, dass Sie auch DeployTarget = Package festlegen können. Dadurch wird das Paket vorbereitet, aber nicht sofort bereitgestellt. Weitere Informationen finden Sie unter dieser Blog-Beitrag .

4
zvolkov

Für mich war das Problem, dass Web Deployment Agent Service wurde nicht gestartet.

Eine einfache net start msdepsvc repariert. Sie können für diesen Dienst auch den Startmodus auf Automatisch setzen.

Die Argumente, die ich benutze, sind:

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:MSDeployPublishMethod=RemoteAgent 
/p:MSDeployServiceUrl=stagingserver 
/p:DeployIisAppPath=test.local 
/p:UserName=

Sie müssen nur den Servernamen und nicht den vollständigen Pfad angeben (kein http erforderlich).

Beachten Sie, dass Benutzername leer bleibt, um einen Fehler bei der NTLM-Authentifizierung zu umgehen (auf diese Weise werden die Anmeldeinformationen des TFS-Build-Agenten für die Bereitstellung verwendet). siehe die akzeptierte Antwort hier

3
andreialecu

Hier ist, wie ich es zum Arbeiten brachte. Dies war mit Webdeploy 2.0. Ich stelle auf der gleichen Domain von unserem Build-Rechner auf einem Dev-Webserver-Rechner Windows Server 2008 R2 bereit. Das Konto, das ich für die Bereitstellung verwende, ist ein Dienstkonto in der Domäne, das auf beiden Computern über Administratorrechte verfügt. Meine Lösung umfasst einige Unit-Test-Projekte, ein MVC3-Projekt und einige Bibliotheken unter der Lösung. Wenn Sie MVC3 nicht auf dem Server installieren, den Sie bereitstellen, lesen Sie http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio zur Orientierung.

/ p: DeployOnBuild = True/p: DeployTarget = MSDeployPublish/p: DeployIisAppPath = "Standardwebsite/YourpplicationNameHere" /p:MsDeployServiceUrl=https://devserver02:8172/msdeploy.axd/p: AllowUntrusted = yourDomain\buildaccount/p: Passwort = Passwort

  1. Der Punkt, mit dem ich zuerst zu kämpfen hatte, waren die Anführungszeichen um "Default Web Site/YourpplicationNameHere", die den teilweisen Fehler ergeben:

    MSBUILD: Fehler MSB1008: Es kann nur ein Projekt angegeben werden.

    Dies geschieht, wenn die Standardwebsite/YourApplicationNameHere nicht in Anführungszeichen steht

  2. Der nächste Fehler, den ich bekam, war der falsche Benutzername und das falsche Passwort in meinen Anmeldeinformationen für die Bereitstellung. Es gab diesen Fehler:

    C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3588): Webbereitstellungstask fehlgeschlagen. (Remote-Agent (URL https: // devserver02: 8172/msdeploy.axd? site = Standard Website) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist.) Stellen Sie sicher, dass Site-Name, Benutzername und Kennwort vorhanden sind richtig. Wenn das Problem nicht behoben ist, wenden Sie sich an Ihren lokalen Administrator oder Serveradministrator. Fehlerdetails: Der Remote-Agent (URL https: // devserver02: 8172/msdeploy.axd? Site = Standard Website) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet ist. Eine nicht unterstützte Antwort wurde empfangen. Der Antwortheader 'MSDeploy.Response' war '', aber 'v1' wurde erwartet. Der Remote-Server hat einen Fehler zurückgegeben: (401) Nicht autorisiert.

    Dies lag daran, dass der Benutzername und das Kennwort, die ich in/p: Benutzername =/p: Kennwort = hatte, nicht die Domäne für den Benutzer enthielten. Obwohl der Build unter diesem Benutzer ausgeführt wurde, wurde er nicht bereitgestellt. Also drücke ich die URL direkt https: // devserver02: 8172/msdeploy.axd in einem Browser, um sicherzustellen, dass es funktioniert, und um sicherzustellen, dass der Benutzername und das Passwort funktioniert haben. Hier ist mir aufgefallen, dass ich die Domain/den Benutzer eingeben muss, damit es funktioniert.

Ich hoffe, das ist in Ordnung zu antworten. Ich dachte mir, dass eine andere arme Seele diese Fehler findet und das könnte helfen.

3
ElvisLives

Wenn Sie Ihre Anwendungen mit fileCopy bereitstellen können, können Sie den TFS-Workflow problemlos anpassen.

Ich habe die CopyDirectory-Aktivität mit Hilfe dieser Artikel verwendet:

http://www.ewaldhofman.nl/post/2010/11/09/Part-14-Execute-a-PowerShell-script.aspx

und

http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx

Sehr einfach und unkompliziert.

  • Ich habe den Build-Dienst mit einem Benutzerkonto konfiguriert, das über Schreibrechte für die gewünschte Freigabe verfügt.

  • Als Nächstes habe ich den Workflow-Schritt CopyDirectory erstellt und die Quelle als BuildDetail.DropLocation + "_PublishedWebsites" konfiguriert. Für das Ziel habe ich ein Argument namens "DeployPath" erstellt, das in die Build-Konfiguration eingegeben werden kann.

  • Jetzt muss ich noch einen Test implementieren, um zu überprüfen, ob der Build erfolgreich war, bevor die CopyDirectory-Aktivität aufgerufen wird. Die Artikel, die ich erwähnte, zeigen, wie man das macht. Sie lernen auch, wie man ein Powershell-Skript anstelle von CopyDirectory aufruft.

1
Sergio Treiger