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

Vishal Joshi bietet hier einen hervorragenden PDC-Vortrag an, in dem die neuen MSDEPLOY-Funktionen in Visual Studio 2010 sowie die Bereitstellung einer Anwendung in TFS beschrieben werden. (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 habe immer wieder verschiedene Fehler. Wenn ich die Paketdatei ausführe, cmdwird sie perfekt bereitgestellt . Wenn ich WebDeploy über Visual Studio ausführe, funktioniert es auch einwandfrei.

Ich möchte jedoch, dass die gesamte Bereitstellung msbuildmithilfe dieser Argumente ausgeführt wird und nicht ein separater Aufruf msdeployoder die Ausführung der Paketdatei .cmd. Wie kann ich das machen?

PS. Ja, ich habe das Web Deployment Agent ServiceRennen. 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 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 wurde.) Fehlerdetail : 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.

IIS7 + verwandte Antwort ....

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

Aber wenn es um die MSBuild-Einstellungen geht, verwenden die meisten Leute hier folgende Einstellungen: Dies /p:MSDeployPublishMethod=RemoteAgentist für IIS7 NICHT RICHTIG. Wenn Sie diese Einstellung verwenden, versucht TFS, eine Verbindung zur URL herzustellen. Um https://your-server-name/MSDEPLOYAGENTSERVICE jedoch auf diese URL zugreifen zu können, muss der zu authentifizierende Benutzer ein Administrator sein. Welches ist fraked. (Und Sie müssen die Admin-Override-Regel aktiviert haben). 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): Webbereitstellungsaufgabe fehlgeschlagen. (Remote-Agent (URL http: // your-web-) Server / 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: 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 dies ändern MSDeployPublishMethod:

/p:MSDeployPublishMethod=WMSVC

Das WMSVCsteht für Windows Manager Service. Es ist im Grunde ein neuer Wrapper über den Remote Agent, aber jetzt können wir einen Benutzernamen und ein Passwort korrekt angeben. Dabei muss der Benutzer KEIN Administrator sein! (Freude!) Jetzt können Sie korrigieren, auf welche Benutzer Sie Zugriff haben möchten .. per WebSite ..

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

Und hier sind meine endgültigen 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 da. Außerdem habe ich in meinem Bild unseren DOMAIN-BENUTZERN Zugriff auf die Website zur Verwaltung gewährt. Als solches hat mein neues Benutzerkonto, das ich hinzugefügt habe (TFSBuildService), eine Mitgliedschaft in der Domain UsersGruppe ... so funktioniert das alles.

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

Hier sind die Schritte, die endlich für mich funktioniert haben. Ich wollte mit RemoteAgent arbeiten, konnte das aber nicht zum Laufen bringen, egal was ich versuchte.

Sie müssen nicht genau so vorgehen, aber so habe ich es zum Laufen gebracht

• Konfigurieren Sie WMSVC
• Stellen Sie sicher, dass der Dienst gestartet ist
• Konfigurieren Sie einen IIS-Benutzer (klicken Sie in IIS auf den TOP MOST SERVERNAME) und gehen Sie zu 'IIS Manager-Benutzer'. Ich schlage vor, es von Ihrem Windows-Namen zu unterscheiden.
• Stellen Sie sicher, dass das Benutzerkonto für WMSVC (LOCAL SERVICE for me) über Schreibberechtigungen für das von Ihnen verwendete IIS-Verzeichnis verfügt
• In meinem Fall verwende ich ein SSL-Zertifikat (obwohl es localhost trifft).

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-Dateieintrag , der auf 127.0.0.1 verweist. Localhost würde wahrscheinlich auch hier funktionieren.

Nützliche Artikel:

Fehlerbehebung bei MSDeploy-Problemen

Weitere Fehlerbehebung

Leider gibt es derzeit nicht viele Informationen dazu. Ich werde Ihnen jedoch am Ende dieser Nachricht einige Hinweise geben.

In Bezug auf Ihr Problem habe ich dies bereits gesehen, als ich versuchte, mit MSDeploy bereitzustellen, und das Konto, auf dem ich ausgeführt wurde, nicht über die Berechtigungen zum Ausführen der Bereitstellung auf dem Zielcomputer verfügte. Sie müssen sich also das Konto ansehen, unter dem Ihre Builds ausgeführt werden, und prüfen, ob dieses Konto die Rechte zur Bereitstellung auf dem Zielcomputer besitzt. 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 definieren MsDeployDestinationProviderSettingund seine Metadaten müssen die erforderlichen Werte enthalten.

Definieren Sie also in Ihrer Projektdatei (oder über übergebene Eigenschaften) Folgendes.

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

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

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

Dadurch wird die Datei importiert, die sich unter befindet %ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, und diese Datei wird wiederum importiert %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 behandelt, aber es wird noch eine ganze 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?

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: // Name meines Servers / p: Benutzername = Benutzername / p: Kennwort = Kennwort

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

Bei Verwendung von InProc (möglicherweise die Standardeinstellung) für 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 bereitgestellt. Ich habe festgestellt, dass die Paketdatei nicht mehr im Ordner MyWebApplication_Package enthalten ist, aber das ist für mich keine große Sache.

Beachten Sie, dass Sie auch DeployTarget = Package festlegen können. Dadurch wird das Paket vorbereitet, aber nicht sofort bereitgestellt. Weitere Informationen finden Sie in diesem Blogbeitrag .

Für mich war das Problem, dass Web Deployment Agent Servicenicht begonnen wurde.

Eine einfache net start msdepsvcLösung. Sie können den Startmodus für diesen Dienst auch auf Automatisch einstellen.

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

So habe ich es zum Laufen gebracht. Dies war mit Webdeploy 2.0. Ich stelle in derselben Domäne von unserer Build-Maschine auf einem Dev-Webserver-Computer Windows Server 2008 R2 bereit. Das Konto, das ich zum Bereitstellen 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, finden Sie weitere Informationen unter http://www.iwantmymvc.com/2011-03-23-bin-deploy-aspnet-mvc-3-visual-studio .

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

1. Das Element, mit dem ich zuerst zu kämpfen hatte, waren die Anführungszeichen um "Standardwebsite / YourpplicationNameHere", die den Teilfehler ergeben:

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

   Dies geschieht, wenn die Standardwebsite / YourApplicationNameHere keine Anführungszeichen enthält

2. Der nächste Fehler, den ich erhielt, war der falsche Benutzername und das falsche Kennwort 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): Webbereitstellungsaufgabe fehlgeschlagen. (Remote-Agent (URL https: // devserver02: 8172 / msdeploy.axd? site = Standardwebsite ) 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 : Remote-Agent (URL https: // devserver02: 8172 / msdeploy.axd? Site = StandardWebsite) 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 Passwort, die ich in / p: UserName = / p: Password = hatte, die Domain für den Benutzer nicht enthielten. Obwohl der Build unter diesem Benutzer ausgeführt wurde, wurde er nicht bereitgestellt. Also habe ich die URL direkt https: // devserver02: 8172 / msdeploy.axd in einem Browser aufgerufen , um sicherzustellen, dass es funktioniert und der Benutzername und das Passwort funktionieren. Hier bemerkte ich, dass ich die Domain / den Benutzer eingeben musste, damit es funktioniert.

Ich hoffe, das ist in Ordnung zu antworten. Ich dachte, eine andere arme Seele hätte diese Fehler gefunden und das könnte helfen ...

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

Ich habe die CopyDirectory-Aktivität mithilfe 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-Service mit einem Benutzerkonto konfiguriert, das über Schreibrechte für die gewünschte Freigabe verfügt.

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

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