Die Antwort finden Sie hier:
http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild
Visual Studio 2010 verfügt über großartige neue Veröffentlichungsfunktionen für Webanwendungsprojekte, mit denen Sie Ihr Webanwendungsprojekt auf Knopfdruck einfach veröffentlichen können. Hinter den Kulissen wird die Web.config-Transformation und die Paketerstellung von einem massiven MSBuild-Skript durchgeführt, das in Ihre Projektdatei importiert wird (zu finden unter: C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft .Web.Publishing.targets). Leider ist das Skript sehr kompliziert, chaotisch und undokumentiert (abgesehen von einigen oft schlecht geschriebenen und meist nutzlosen Kommentaren in der Datei). Ein großes Flussdiagramm dieser Datei und einige Dokumentationen zum Einbinden wären nett, scheinen aber leider zu fehlen (oder zumindest kann ich sie nicht finden).
Leider bedeutet dies, dass das Veröffentlichen über die Befehlszeile viel undurchsichtiger ist, als es sein muss. Ich war überrascht über den Mangel an Dokumentation in diesem Bereich, da heutzutage viele Geschäfte einen kontinuierlichen Integrationsserver verwenden und einige sogar eine automatisierte Bereitstellung durchführen (bei der die VS2010-Veröffentlichungsfunktionen sehr hilfreich sein könnten). Ich hätte also gedacht, dass dies möglich ist ( leicht!) wäre eine ziemlich wichtige Voraussetzung für die Funktion gewesen.
Nachdem ich mich stundenlang in der Microsoft.Web.Publishing.targets-Datei umgesehen und meinen Kopf gegen die Trial-and-Error-Wand geschlagen habe, habe ich es geschafft, herauszufinden, wie Visual Studio seine magische Wirkung mit einem Klick auf "In Dateisystem veröffentlichen" zu entfalten scheint. und Funktionen zum Erstellen eines Bereitstellungspakets. Ich werde mich mit MSBuild-Skripten befassen. Wenn Sie also nicht mit MSBuild vertraut sind, empfehlen wir Ihnen, diese MSDN-Seite des Crashkurses zu lesen.
Im Dateisystem veröffentlichen
Es dauerte eine Weile, bis ich das Dialogfeld "In Dateisystem veröffentlichen" für VS2010 veröffentlicht hatte, da ich erwartet hatte, dass MSBuild sinnvoll eingesetzt wird. Stattdessen macht VS2010 etwas ziemlich Seltsames: Es fordert MSBuild auf, eine Art Halbbereitstellung durchzuführen, die die Dateien der Webanwendung im obj-Ordner Ihres Projekts vorbereitet, und dann scheint es eine manuelle Kopie dieser Dateien zu erstellen (dh außerhalb von MSBuild). in Ihren Zielveröffentlichungsordner. Dies ist ein wirklich verrücktes Verhalten, da MSBuild zum Kopieren von Dateien (und anderen Build-bezogenen Dingen) entwickelt wurde. Es wäre also sinnvoll, wenn der gesamte Prozess nur ein von VS2010 aufgerufenes MSBuild-Ziel wäre, kein Ziel, sondern eine manuelle Kopie.
Dies bedeutet, dass dies über MSBuild in der Befehlszeile nicht so einfach ist wie das Aufrufen Ihrer Projektdatei mit einem bestimmten Ziel und das Festlegen einiger Eigenschaften. Sie müssen das tun, was VS2010 hätte tun sollen: Erstellen Sie selbst ein Ziel, das die Halbbereitstellung durchführt, und kopieren Sie die Ergebnisse in den Zielordner. Um Ihre Projektdatei zu bearbeiten, klicken Sie mit der rechten Maustaste auf das Projekt in VS2010 und klicken Sie auf Projekt entladen. Klicken Sie dann erneut mit der rechten Maustaste und klicken Sie auf Bearbeiten. Scrollen Sie nach unten, bis Sie das Import-Element finden, das die Webanwendungsziele importiert (Microsoft.WebApplication.targets; diese Datei selbst importiert die zuvor erwähnte Microsoft.Web.Publishing.targets-Datei). Unter dieser Zeile fügen wir unser neues Ziel namens PublishToFileSystem hinzu:
<Target Name="PublishToFileSystem"
DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">
<Error Condition="'$(PublishDestination)'==''"
Text="The PublishDestination property must be set to the intended publishing destination." />
<MakeDir Condition="!Exists($(PublishDestination))"
Directories="$(PublishDestination)" />
<ItemGroup>
<PublishFiles Include="$(_PackageTempDir)\**\*.*" />
</ItemGroup>
<Copy SourceFiles="@(PublishFiles)"
DestinationFiles="@(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')"
SkipUnchangedFiles="True" />
</Target>
Dieses Ziel hängt vom PipelinePreDeployCopyAllFilesToOneFolder-Ziel ab, das VS2010 aufruft, bevor es manuell kopiert wird. Einige Untersuchungen in Microsoft.Web.Publishing.targets zeigen, dass beim Aufrufen dieses Ziels die Projektdateien in dem durch die Eigenschaft _PackageTempDir angegebenen Verzeichnis abgelegt werden.
Die erste Aufgabe, die wir in unserem Ziel aufrufen, ist die Fehleraufgabe, für die wir eine Bedingung festgelegt haben, die sicherstellt, dass die Aufgabe nur ausgeführt wird, wenn die PublishDestination-Eigenschaft nicht festgelegt wurde. Dadurch werden Sie abgefangen und der Build wird fehlerhaft, falls Sie vergessen haben, die PublishDestination-Eigenschaft anzugeben. Wir rufen dann die MakeDir-Task auf, um dieses PublishDestination-Verzeichnis zu erstellen, falls es noch nicht vorhanden ist.
Anschließend definieren wir ein Element namens PublishFiles, das alle im Ordner _PackageTempDir gefundenen Dateien darstellt. Anschließend wird die Aufgabe "Kopieren" aufgerufen, mit der alle diese Dateien in den Ordner "Ziel veröffentlichen" kopiert werden. Das DestinationFiles-Attribut für das Copy-Element ist etwas komplex. Es führt eine Transformation der Elemente durch und konvertiert ihre Pfade in neue Pfade, die im Ordner PublishDestination verwurzelt sind (überprüfen Sie die Metadaten bekannter Elemente, um zu sehen, was diese% () bedeuten).
Um dieses Ziel über die Befehlszeile aufzurufen, können wir jetzt einfach diesen Befehl ausführen (offensichtlich ändern Sie den Namen und die Eigenschaften der Projektdatei entsprechend Ihren Anforderungen):
msbuild Website.csproj "/p:Platform=AnyCPU;Configuration=Release;PublishDestination=F:\Temp\Publish" /t:PublishToFileSystem
Condition="false"ist aus Gründen der Abwärtskompatibilität vorhanden. Für VS2010 muss dieser Import vorhanden sein, auch wenn er aufgrund der falschen Bedingung übersprungen wird. Wenn Sie noch einmal nachsehen, werden Sie feststellen, dass das csproj einen weiteren Import enthält,$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targetsder in die Zieldatei für die aktuelle Version von Visual Studio aufgelöst wird.