Ich versuche, Visual Studio Online so zu konfigurieren, dass meine ASPNET 5-Anwendung kontinuierlich in einer Azure-Webanwendung bereitgestellt wird, wie in diesem Lernprogramm in den Team Foundation Build-Dokumenten beschrieben:https: //msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet

Ich habe alle Schritte befolgt und alles funktioniert super. Standardmäßig stellt dieses Skript einen Build meiner App bereit, der auf die vollständige .Net 4.5.1-DNX-Version abzielt. Daher habe ich beschlossen, ihn so zu ändern, dass er für .Net Core bereitgestellt wird.

Das Erstellungsskript erstellt sein Bereitstellungspaket durch Aufrufen von:msbuild.exe /t:Build,FileSystemPublish Nachdem ich die Ausführlichkeit des Protokolls aufgedeckt und die relevanten msbuild-Dateien gelesen habe, habe ich Folgendes gelernt:

Das "Build" -Ziel verwendet letztendlich dnx.exe, um das Projekt zu kompilieren. Da die Datei project.json sowohl dnx451- als auch coreclr-TFMs enthält, werden in diesem Schritt Build-Ausgaben für beide Frameworks erstellt - soweit so gut.

Das FileSystemPublish-Ziel scheint jedoch nur ein msdeploy-Paket auszugeben, das auf die .Net 4.5.1-Laufzeit abzielt. Aus den Protokollen konnte ich ersehen, dass das Ausführen des FileSystemPublish-Ziels letztendlich einen "dnu publish" -Befehl ausgibt und in meinen Fällen "dnx-clr-win-x86.1.0.0-beta6" als -runtime-Parameter übergibt. Als ich den Navigationspfaden folgte, um herauszufinden, woher der Wert "dnx-clr-win-x86.1.0.0-beta6" stammt, landete ich schließlich in der Aufgabe "GetRuntimeToolingPath" in Microsoft.DNX.Tasks.dll. Diese Task scheint in global.json nach der richtigen zu verwendenden Laufzeit zu suchen, überschreibt diesen Wert jedoch seltsamerweise intern mit "x86" und "clr", bevor die Rückgabezeichenfolge erstellt wird.

Wenn ich die Dinge richtig interpretiert habe, scheint es, dass das FileSystemPublish-Ziel (in Microsoft.DNX.Publishing.targets) im Wesentlichen (indirekt) fest verdrahtet ist, um das vollständige x86.Net-Framework DNX zu verwenden, wenn es seine Paketausgabe erzeugt. An dieser Stelle stecke ich fest, wie ich diesen Build-Prozess zum Erstellen eines .Net Core-Pakets bekomme.

Meine Frage ist, warum FileSystemPublish mit dem x86-Voll-.Net-DNX gekoppelt werden soll und in Anbetracht dessen, dass dies der Fall zu sein scheint (sofern ich mich nicht irre), was die empfohlene Methode ist, um ein msdeploy-Paket für eine ASPNET 5-App zu erstellen, die auf den .Net-Kern abzielt ?

BEARBEITEN Im Moment habe ich einen Workaround. Ich kann @ übergeb/p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" als Parameter für msbuild. Dies überschreibt die Standardlogik in GetRuntimeToolPath und erzwingt die Verwendung von .Net Core. Dies funktioniert, fühlt sich aber wie ein Hack an, sodass ich die Frage offen lasse, um eine bessere Antwort zu erhalten.