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

78

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.

Simon_Weaver
quelle
@pure ich war auch ziemlich enttäuscht. Ich hoffe, Sie haben es am Ende zum Laufen gebracht. Für Teams ohne einen engagierten (überbezahlten) Build-Typ sollte es wirklich einfacher sein. obwohl es im Vergleich zu der Facebook-Integration, an der ich in letzter Zeit gearbeitet habe, ein Kinderspiel ist!
Simon_Weaver
heh :) das habe ich heute endlich gemacht. Sie arbeitet, sie arbeitet!
Pure.Krome
4
@shaun - nein, es funktioniert gut, wenn Sie wissen, wie man es benutzt ;-)
Simon_Weaver
1
Frage mit Liste der Optionen: stackoverflow.com/questions/5598668/…
Tim Abell
4
@ Simon_Weaver Vielleicht ist dieser Build-Typ doch nicht so überbezahlt ;-)
Damien Ryan

Antworten:

48

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 ..

Geben Sie hier die Bildbeschreibung ein

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!)

Geben Sie hier die Bildbeschreibung ein

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) ....

Geben Sie hier die Bildbeschreibung ein

Pure.Krome
quelle
Fantastische Antwort. Ich wollte für jeden hinzufügen, der es benötigt. Das gesuchte Ziel ist WebMSDeployPublish, wenn Sie die Build- und Bereitstellungsschritte trennen möchten. (Also anstelle von / t: Build / p: DeployOnBuild = True hätten Sie nur / t: WebMSDeployPublish.)
Moswald
Follow-up zu meinem letzten Beitrag: Das WebMSDeployPublish ist nur für die VS 11 Developer Preview verfügbar. Hoppla.
Moswald
3
Ihre Antwort hat mein Leben in vielerlei Hinsicht verbessert. Ich bin mir nicht sicher, warum Microsoft diese Informationen nicht so komprimieren konnte.
Michael McGuire
3
Du mein Freund bist ein Rockstar. Ich habe meinen Kopf dagegen geschlagen und versucht, auf jede Art und Weise und am Ende mit dem WMSVC für mich zu arbeiten.
Uadrive
msbuild hat die Bereitstellung für mich immer noch stillschweigend umgangen. Diese Antwort führte mich zum Sieg stackoverflow.com/a/15543183/141508 ; Ich musste auch das Verzeichnis C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ Web von meiner Entwicklungsbox auf meinen Buildserver kopieren .
Paul Smith
19

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

Simon_Weaver
quelle
6
Zu Ihrer Information - / p: SkipExtraFilesOnServer = true behält die vorhandene Site bei.
NotMe
@ Chris Ich habe überall nach dieser Immobilie gesucht
Joseph
@ Joseph: Ich erinnere mich nicht, wo ich es endlich gefunden habe, aber ich bin froh, dass dir das geholfen hat!
NotMe
eine Frage an dich. Das / p: DeployTarget = MSDeployPusblish arbeitete für meinen von TFS verwalteten Build, um sich nach Abschluss selbst bereitzustellen. Das einzige Problem ist, dass die web.config-Transformation falsch ist. Gibt es eine Möglichkeit, die web.config-Transformation zu erzwingen, damit sie für eine bestimmte Konfiguration funktioniert?
Michael McCarthy
16

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?

Sagte Ibrahim Hashimi
quelle
Ich habe es endlich geschafft, aber nur über WMSVC und nicht über RemoteAgent. Ich konnte es nicht dazu bringen, eine Verbindung zum Remote-Agenten herzustellen, egal welche URL ich ausprobiert habe
Simon_Weaver
1
OK, jetzt, wo Sie es erwähnen, denke ich, dass WMSVC für https erforderlich ist. Das habe ich nicht beachtet.
Sagte Ibrahim Hashimi
1
Ich bin mir ziemlich sicher, dass ich es mit oder ohne versucht habe. Es ist mir egal, welche ich benutze - ich kann nur nicht sehen, warum der RemoteAgent nicht funktioniert hat
Simon_Weaver
Ist es möglich, Windows Auth zu verwenden, anstatt einen Benutzernamen und ein Passwort zu codieren?
Maslow
Sayeds Kommentar zu WMSVC war ein wichtiger Punkt für mich. Wenn Sie versucht haben, eine https-Adresse an den msdeploy-Dienst zu senden, wurde auch eine http-Adresse angehängt. Wenn Sie von 'RemoteAgent' zu WMSVC wechseln, wird die Adresse mit https als Literal verwendet, was dann für mich funktioniert hat.
Der Senator
6

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.

Chad Peck
quelle
Ich habe alle Arten von Variationen für MsDeployServiceUrl ausprobiert. Ich erhalte immer Folgendes: VsMsdeploy ist fehlgeschlagen. (Remote-Agent (URL localhost / MSDEPLOYAGENTSERVICE? site = staging.example.com ) konnte nicht kontaktiert werden. Stellen Sie sicher, dass der Remote-Agent-Dienst auf dem Zielcomputer installiert und gestartet wurde.) Fehlerdetails : Remote-Agent (URL localhost / MSDEPLOYAGENTSERVICE? Site = staging.rollingrazor.com ) konnte nicht kontaktiert werden
Simon_Weaver
es scheint so, als ob das funktionieren sollte - aber genau das hatte Vishal in seinem Vortrag. Auf den Agentendienst kann definitiv zugegriffen werden : Wenn ich im Browser auf localhost / MSDEPLOYAGENTSERVICE drücke, wird ein Protokolleintrag in C: \ Windows \ ServiceProfiles \ NetworkService \ AppData \ Local \ Temp \ MSDepSvc.log hinzugefügt
Simon_Weaver
1
Wie haben Sie angegeben, wo Ihre drei Anwendungen in einer Lösung bereitgestellt wurden?
GWLlosa
4

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 .

zvolkov
quelle
3

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

andreialecu
quelle
3

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 ...

ElvisLives
quelle
1

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.

Sergio Treiger
quelle