Nach der Aktualisierung der Lösung auf .NET Framework 4.5 stoppte die tägliche Bereitstellung

Question

Wir haben mit Erfolg unsere Entwicklungs-Website täglich mit msdeploy von TFS2010 aktualisiert.

Dies funktionierte gut, bis wir auf VS2012, unsere Anwendung von .NET Framework 4.0 auf 4.5 und ASP.NET MVC von 3.0 auf 4.0 aktualisiert. Es sieht so aus, als ob alles in Ordnung ist und Assemblys bereitgestellt werden, aber nichts wurde tatsächlich bereitgestellt.

Ich habe das seit zwei Tagen untersucht und kann nicht herausfinden, warum das passiert und jetzt sind mir die Ideen ausgegangen.

Unten ist ein Teil meines Build-Skripts in der Art, wie es vor dem Upgrade funktioniert hat.

<MSBuild 
       Projects="$(SolutionRoot)\My.Web\My.Web.csproj" 
       Properties="MvcBuildViews=False;AllowUntrustedCertificate=True;AuthType=Basic;Configuration=Dev;CreatePackageOnPublish=True;DeployIisAppPath=dev.myweb;DeployOnBuild=True;DeployTarget=MsDeployPublish;MSDeployPublishMethod=WMSvc;MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd;UserName=UserName;Password=Password;UseMsdeployExe=True" 
       ContinueOnError="False" 
       /> 

Wenn das Upgrade initiiert wurde und mein Problem entdeckt wir Web Deploy 2.0 wurden mit, aber jetzt haben wir Web Deploy 3.0 aktualisiert. Ich habe auch dafür gesorgt, dass wir mit ToolsVersion="4.0" bauen.

UPDATE -

msbuild.exe/p: AllowUntrustedCertificate = True /p: AuthType = Basis /p: Konfiguration = Dev /p: CreatePackageOnPublish = True /p: DeployIisAppPath = dev .myweb /p: DeployOnBuild = True /p: DeployTarget = MsDeployPublish /p: MSDeployPublishMethod = WMSVC /p:MsDeployServiceUrl=https://10.xxx.xxx.xxx:8172/MsDeploy.axd /p: UserName = Benutzername /p: Passwort = Passwort /p: UseMsdeployExe = True E: \ Builds \ 1 \ Ganz gleich, ob \ Daily_Build \ Sources \ My.Web \ My.Web.csproj

nun den oben msbuild Befehl aus unserer TFS und keine Antwort, die ich auch versucht, laufen was mich völlig frustriert. Nichts im Ereignisprotokoll von TFS, nichts in Protokolldatei, egal Ausführlichkeit ... Irgendwelche Ideen?

Es funktioniert mit msdeploy directy wie unten;

<Exec Command="&quot;C:\Program Files\IIS\Microsoft Web Deploy V3\MSDeploy.exe&quot; -verb:sync -source:contentPath=&quot;E:\Builds\1\WhatEver\Daily_Build\Sources\My.Web\My.Web.csproj&quot; -dest:contentPath=&quot;E:\dev.my.web&quot;,computername=https://10.xxx.xxx.xxx:8172/MsDeploy.axd,username=UserName,password=Password,authtype=Basic -allowUntrusted=True" 
       ContinueOnError="false" /> 

-

UPDATE 2- Es scheint Microsoft einen Scheck für welche Art von Projekten, die zur Veröffentlichung geeignet Projekte und unsere Web-Anwendung nicht, da der Typ hinzugefügt Ausgang ist Klassenbibliothek. Dies war mit v4.0 gültig, aber anscheinend nicht für v4.5.

Jeder hat eine Idee, was zu tun ist, damit es wieder funktioniert? Muss ich den Projekttyp ändern? Publishing-Paket vorab erstellen und dann bereitstellen? Oder was?

-

Jeder andere, die das gleiche Problem gehabt hat? Haben Sie eine Lösung zum Teilen gefunden?

Könnte es ein Problem mit der Version von MSBuild geben?

Answer 1

Hier ist, was ich empfehlen würde.In VS2012 haben wir das Publizieren Ihrer Webprojekte mithilfe der Veröffentlichungsprofile, die im Veröffentlichungsdialog erstellt wurden, vereinfacht. Erstellen Sie in Ihrem Fall ein neues MSDeploy-Profil. Wenn Sie dieses Profil erstellen, speichern wir die Einstellungen in einer Datei unter Properties \ PublishProfiles (oder My Project \ PublishProfiles for VB). Die Erweiterung dieser Datei wird .pubxml sein. Diese Dateien sind eigentlich MSBuild-Dateien, die Sie bei Bedarf anpassen können. Sie können den Veröffentlichungsdialog weiterhin verwenden. Das Passwort wird in einer .user-Datei gespeichert und so verschlüsselt, dass nur Sie es entschlüsseln können.

Nachdem Sie dieses Profil erstellt haben, können Sie mit dem folgenden Befehl veröffentlichen, wenn Sie die .sln-Datei erstellen.

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> 

Wenn Sie bauen die CSPROJ/.vbproj dann müssen Sie diese ein wenig in der folgenden Art und Weise optimieren

msbuild mysoln.sln /p:DeployOnBuild=true /p:PublishProfile=<ProfileName> /p:Password=<Password> /p:VisualStudioVersion=11.0 

Mehr darüber, warum VisualStudioVersion bei http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx erforderlich ist.

Sobald Sie dies tun, können Sie + veröffentlichen, wie Sie es zuvor getan haben. Zu Ihrer Information: Wir haben alle diese neuen Webveröffentlichungsfunktionen für VS2010 im Azure SDK https://www.windowsazure.com/en-us/develop/net/# bereitgestellt.

Auch in Ihrer Frage habe ich festgestellt, dass Sie einige benutzerdefinierte Eigenschaften wie MvcBuildViews angeben. Sie können diese Eigenschaften jetzt direkt in das Veröffentlichungsprofil (die .pubxml-Datei) einfügen, wenn Sie möchten. Natürlich können Sie sie auch in der Befehlszeile übergeben, wenn dies für Ihr Szenario sinnvoller ist.

Weitere Informationen hierzu unter http://sedodream.com/2012/06/15/VisualStudio2010WebPublishUpdates.aspx.

Wenn Sie sich die Vorgehensweise ansehen, mit der Entwickler die Veröffentlichung automatisieren konnten, sollten Eigenschaften und Ziele angegeben werden, die während des Builds ausgeführt werden. Das Problem mit diesem Ansatz besteht darin, dass dies unsere Möglichkeiten einschränkt, die Web-Publisher-Erfahrung zu verbessern. In der neuen Version haben wir eine Abstraktion eingeführt, das Publish-Profil, mit dem wir die zugrunde liegenden Ziele der Web-Publishing-Pipeline ändern können und Ihre Automatisierungsskripts weiter laufen. Hoffentlich müssen Sie dieses Thema von diesem Punkt an nicht erneut besuchen.

Answer 2

Ich hatte heute das gleiche Problem. Ich habe auch versucht, eine .NET 4.5-Webanwendung automatisch mit einem Computer zu installieren, auf dem Visual Studio 2012 nicht installiert war. Es gab jedoch ein paar kleine Unterschiede in meiner Situation: Ich habe TeamCity anstelle von TFS verwendet, und unsere Lösung wurde mit .NET 4.5 erstellt, im Gegensatz zu einem, das von .NET 4.0 aktualisiert wurde.

Trotzdem hatte ich das gleiche Problem beschrieben. Ich würde MSBuild verwenden, um die Webanwendung auf ähnliche Weise zu erstellen und auf IIS bereitzustellen. Dieser Ansatz hat auf meiner Entwicklungsmaschine gut funktioniert. Als ich jedoch MSBuild auf dem CI-Server ausgeführt habe, hat es die Web-App ziemlich glücklich gebaut, aber es hat danach aufgehört: keine Fehler, keine Warnungen, nichts, nur eine Nachricht, dass der Build erfolgreich war. Es gab nicht den geringsten Hinweis auf einen Versuch, die App für IIS bereitzustellen.

Es scheint, MSBuild fehlte die relevanten Ziele, um die Webbereitstellung durchzuführen. Der Fehler bestand darin, den Ordner C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web von meinem Entwicklungscomputer auf den CI-Server zu kopieren und ihn an den gleichen Ort auf dem CI-Server zu kopieren, wie er auf meinem Computer war.

Sobald ich das getan habe, murrte MSBuild dann über Web Deploy 3.0, aber das wurde einfach genug behoben. Nach der Installation auf dem CI-Server hat MSBuild die Web-App ziemlich glücklich bereitgestellt.

Answer 3

Luke Woodward's answer zu erweitern:

Ich fand auch, dass C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ von meinem lokalen Rechner auf den Build-Server bereitstellen das Update war.

Die eigentliche Lösung besteht jedoch darin, die Microsoft Web Developer Tools als Teil der VS 2012-Installation zu installieren, die unter anderem diesen Ordner erstellt. Dies betrifft Ieppies Einspruch gegen die Lizenzierung.

testete ich dies ...

1. löschen C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\
2. das Installationsprogramm VS 2012 Laufen und das Hinzufügen von MS Web Dev-Tools.
3. Überprüfen, dass nach der Installation C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\ zurück war.