web-dev-qa-db-de.com

MSBuild-Bereitstellung schlägt nach dem Upgrade auf .NET 4.5 fehl

Wir haben kürzlich unsere VS 2010- und .NET 4-Anwendung auf VS 2012 und .NET 4.5 aktualisiert. Wir haben ein Build-Skript, um die Anwendung auf dem Testserver bereitzustellen. Wir haben zwei Boxen - eine ist Windows 8 mit VS 2012 (Neuinstallation) und die andere ist Windows 7 mit VS 2010 und VS 2012 (Neuinstallation).

Wenn Sie das Build-Skript unter Windows 8 ausführen, funktioniert das Build-Skript einwandfrei und stellt die Anwendung auf dem Testserver bereit. Bei der Bereitstellung der Anwendung unter Windows 7 wird jedoch die folgende Fehlermeldung angezeigt:

"C:\Achinth\Build\Work\build\qa1sb.proj" (DeployAll-Ziel) (1) -> "C:\Achinth\Build\Work\App\App.csproj" (ResolveReferences; MsDeployPublish-Ziel) (2) -> (MSDeployPublish-Ziel) -> C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): Fehler: Webbereitstellungstask fehlgeschlagen. ( (19.08.2012, 18:23:41 Uhr) Beim Verarbeiten der Anforderung auf dem Remotecomputer ist ein Fehler aufgetreten.) [C:\Achinth\Build\Work\App\App.csproj] C:\Programme (x86 )\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): Fehler:\r [C:\Achinth\Build\Work\App\App.csproj] C:\Programmdateien (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (3847,5): Fehler: (19.08.2012, 18:23:41 Uhr) Beim Auftreten eines Fehlers Die Anforderung wurde auf dem Remotecomputer verarbeitet.\r [C:\Achinth\Build\Work\App\App.csproj] C:\Programme (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft. Web.Publishing.targets (3847,5): Fehler: Der Anwendungspool t Bei dem von Ihnen verwendeten Objekt ist die Eigenschaft 'managedRuntimeVersion' auf 'v4.0' gesetzt. Diese Anwendung benötigt 'v4.5'. [C:\Achinth\Build\Work\App\App.csproj]

Betrachtet man den Fehler, sieht es so aus, als würde MSBuild VS 2010-Ziele anstelle von VS 2012 verwenden, was den Fehler verursacht. Da Windows 8 nicht über VS 2010 verfügt, werden VS 2012-Ziele ordnungsgemäß verwendet.

Kann jemand bitte Hinweise geben, wie man MSBuild dazu bringt, die richtige Version auszuwählen?

47
Achinth Gurkhi

In diesem Fall müssen Sie die MSBuild-Eigenschaft VisualStudioVersion = 11.0 angeben. Ich habe gerade unter http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx darüber gebloggt.

Eine der am häufigsten nachgefragten Funktionen von Visual Studio 2012 war die Möglichkeit, Projekte sowohl in VS 2012 als auch in VS 2010 zu öffnen (erfordert VS 2010 SP1). Falls Sie noch nichts gehört haben, haben wir diese Funktion implementiert. Sie fragen sich vielleicht, wie wir das geschafft haben und wie sich das auf Sie auswirken könnte.

Wenn Sie die Datei .csproj/.vbproj für ein in VS2010 erstelltes Webprojekt öffnen, wird die folgende Importanweisung angezeigt.

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

Wenn Sie dieses Projekt in VS 2012 öffnen, werden einige Änderungen an Ihrer Projektdatei vorgenommen, um sicherzustellen, dass es sowohl in VS 2010 SP1 als auch in VS 2012 geöffnet werden kann. Eine der Änderungen, die beim ersten Laden des Projekts in VS 2012 vorgenommen wurden Fügen Sie Folgendes hinzu, um diese Importanweisung zu ersetzen.

<PropertyGroup>
  <VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
  <VSToolsPath Condition="'$(VSToolsPath)' == ''">
    $(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />

Wir haben die hartcodierte Version 10.0 entfernt und stattdessen die Eigenschaft VisualStudioVersion verwendet. Beim Erstellen in Visual Studio 2012 beträgt dieser Wert immer 11,0, für VS 2010 ist er jedoch nicht vorhanden. Aus diesem Grund haben wir den Standardwert auf 10.0 gesetzt. Es gibt einige Szenarien, in denen das Erstellen über die Befehlszeile das explizite Festlegen dieser Eigenschaft erfordert. Bevor wir dort ankommen, lassen Sie mich erklären, wie diese Eigenschaft festgelegt wird (in dieser Reihenfolge)

  1. Wenn VisualStudioVersion als Umgebungsvariable/globale MSBuild-Eigenschaft definiert ist, wird diese verwendet.
    • Auf diese Weise setzen VS und die VS Developer-Eingabeaufforderung diesen Wert
  2. Basierend auf der Dateiformatversion der SLN-Datei (verwendetes Toolset ist SLN-Dateiformat –1)
    • Um diese Anweisung zu vereinfachen, wird in der SLN-Datei VisualStudioVersion mit dem Wert der VS-Version angegeben, die die SLN-Datei erstellt hat.
  3. Standard auswählen
    • 10.0, wenn VS 2010 installiert ist
    • Version des Sub-Toolset mit der höchsten Version installiert

Für # 2, wenn Sie eine SLN-Datei erstellen, ist der Wert von VisualStudioVersion –1 der Formatversion, die in der SLN-Datei enthalten ist. Hierbei ist zu beachten, dass beim Erstellen einer SLN-Datei der Wert von VisualStudioVersion verwendet wird, der der VS-Version entspricht, mit der die SLN-Datei erstellt wurde. Wenn Sie also in VS2012 eine SLN-Datei erstellen und diese SLN-Datei immer erstellen, lautet der Wert für VisualStudioVersion 11.0. In vielen Fällen sind Sie gut, wenn Sie die SLN-Datei erstellen.

Wenn Sie .csproj/.vbproj-Dateien erstellen, ohne eine .sln-Datei zu durchlaufen? Wenn Sie ein Webprojekt über die Befehlszeile erstellen (nicht über die Eingabeaufforderung des Entwicklers), lautet der Wert für VisualStudioVersion 10.0. Das ist ein Artefakt der Eigenschaften, die ich oben gezeigt habe. In diesem Fall sollten Sie dies als MSBuild-Eigenschaft übergeben. Beispielsweise

msbuild.exe MyAwesomeWeb.csproj /p:VisualStudioVersion=11.0

In diesem Fall gebe ich die Immobilie ausdrücklich weiter. Dies überschreibt immer jeden anderen Mechanismus, um den Wert für VisualStudioVersion zu bestimmen. Wenn Sie die MSBuild-Aufgabe in einem Erstellungsskript verwenden, können Sie die Eigenschaft entweder im Attribut Properties oder im Attribut AdditionalProperties angeben. Weitere Informationen zum Unterschied zwischen "Properties" und "AdditionalProperties" finden Sie in meinem vorherigen Blogbeitrag.

Wenn Sie beim Erstellen/Veröffentlichen auf ein komisches Verhalten stoßen und feststellen, dass die falschen .targets-Dateien importiert werden, müssen Sie möglicherweise diese Eigenschaft angeben.

58

von dieser Link .

"Öffnen Sie Ihre * .csproj - oder * .vbproj - Webprojektdatei in einem Texteditor und fügen Sie die folgende Zeile hinzu.

<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion> 

Ich habe die Zeile kurz vor der Zeile hinzugefügt

<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>

und es wird ohne Fehler bereitgestellt. "

Es hat bei mir funktioniert.

41

Ich habe festgestellt, dass bei Verwendung der VS2012 Publish Web Deploy Package-Funktion eine ZIP-Datei generiert wird. In diesem Zip befindet sich eine Datei namens archive.xml, die ein createApp-Tag mit dem Attribut 'managedRuntimeVersion = "v4.0"' enthält. Wenn ich msdeploy.exe verwende, um es mit einer iis-Instanz zu synchronisieren, funktioniert es.

Wenn ich jedoch msbuild.exe verwende, um eine ZIP-Datei für ein Webpaket zu erstellen, enthält diese eine archive.xml mit 'managedRuntimeVersion = "v4.5"'. Der Versuch, dieses Webpaket unter Verwendung von msdeploy.exe in IIS= zu implementieren, führt zu dem Fehler ERROR_APPPOOL_VERSION_MISMATCH.

Wie Sayed Ibrahim Hashimi hier erklärte, erzwingt das Hinzufügen von "/p:VisualStudioVersion=11.0" zu meiner msbuild.exe-Befehlszeile effektiv "managedRuntimeVersion =" v4.0 "" in der archive.xml des resultierenden Webpakets, damit das Problem behoben wird.

2
sevzas

Für alle, die auf dieser Seite nach dem Grund gesucht haben, warum msdeploy/webdeploy einen ähnlichen Fehler anzeigt, war dies die Lösung.

Um das Problem zu beheben, fügen Sie einfach die Eigenschaft DeployManagedRuntimeVersion in Ihr VS-Projekt ein:

<targetframeworkversion>v4.5</TargetFrameworkVersion></code>
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>

Von hier aus: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html

2
misterduck

In meinem Fall wurde WebDeploy nicht auf dem Build-Server installiert. Also warf es einen ähnlichen Fehler. Ich habe WebDeploy installiert und war begeistert.

http://www.Microsoft.com/en-ca/download/confirmation.aspx?id=252

0
mithun_daa