MSDN Magazin > Home > Ausgaben > 2007 > April >  Extreme ASP.NET: Webbereitstellungsprojekte
Extreme ASP.NET
Webbereitstellungsprojekte
Fritz Onion

Als ASP zuerst veröffentlicht wurde, war Internetprogrammierung noch schwieriger, weil für ASP-Seiten ISS erforderlich war. Durch die Einführung des Websitemodells für die Entwicklung mit ASP.NET 2.0 und Visual Studio® 2005 wurde alles leichter. Anstatt ein neues Projekt in Visual Studio zu erstellen, können Sie mit dem Websitemodell auf ein Verzeichnis zeigen und sofort Seiten und Code schreiben. Ferner können Sie Ihre Site mit dem integrierten ASP.NET Development Server testen, der ASP.NET in einem lokalen Prozess hostet und damit die Installation von IIS vor Entwicklungsbeginn unnötig macht. Der Vorteil des Websitemodells ist, dass Sie Ihre Webanwendung entwickeln können, ohne an das Verpacken oder Bereitstellen denken zu müssen. Sie benötigen eine weitere Klasse? Fügen Sie im Verzeichnis „App_Code“ eine CS-Datei hinzu, und beginnen Sie mit dem Schreiben. Möchten Sie lokalisierbare Zeichenfolgen in einer Ressourcendatei speichern? Fügen Sie im Verzeichnis „App_GlobalResources“ eine RESX-Datei hinzu, und geben Sie die Zeichenfolgen ein. Alles funktioniert sofort – Sie müssen überhaupt nicht an den Kompilierungs- und Bereitstellungsaspekt denken.
Wenn Sie soweit sind, können Sie zwischen mehreren Bereitstellungsmöglichkeiten wählen. Die einfachste Möglichkeit ist, Ihre Dateien auf einen Liveserver zu kopieren und alles bei Bedarf kompilieren zu lassen (wie schon in Ihrer Testumgebung). Die zweite Möglichkeit ist, das Dienstprogramm „aspnet_compiler.exe“ zu verwenden und die Anwendung in eine Binärversion vorzukompilieren, wodurch nur noch eine Sammlung von Assemblys, statischen Inhalten und Konfigurationsdateien bleibt, die Sie auf den Server übertragen. Die dritte Möglichkeit besteht darin, wieder „aspnet_compiler.exe“ zu verwenden, aber dabei eine aktualisierbare Binärbereitstellung zu erstellen, bei der alle AS*X-Dateien intakt (und modifizierbar) bleiben und alle Ihre Codedateien in binäre Assemblys kompiliert werden.
Jedes mögliche Szenario scheint abgedeckt. Der Entwickler kann sich einfach auf das Schreiben der Webanwendung konzentrieren und die Verpackungs- und Bereitstellungsentscheidungen später treffen, wenn die Anwendung tatsächlich bereitgestellt wird. Es gab jedoch recht großen Widerstand gegen dieses Modell, insbesondere seitens der Entwickler, die es gewohnt waren, dass Ihre Webprojekte echte Projekte darstellten und in echten Projektdateien angelegt wurden, in denen sie Funktionen vor und nach dem Build einfügen konnten, Dateien vom Buildprozess ausschließen konnten, mit einem Befehlszeilenschalter vom Debug- in das Versionsbuild wechseln konnten und so weiter. Als Reaktion darauf hat Microsoft schnell das Webanwendungsprojekt oder WAP eingeführt, das anfänglich als Add-In zu Visual Studio 2005 veröffentlicht wurde und jetzt in Visual Studio 2005 Service Pack 1 (SP1) enthalten ist. Es steht unter msdn.microsoft.com/vstudio/support/vs2005sp1 zum Download bereit.
WAP stellt eine Alternative zum Websitemodell dar, die dem Webprojektmodell von Visual Studio .NET 2003 viel ähnlicher ist. Im neuen WAP-Modell werden alle Quellcodedateien während des Buildprozesses kompiliert, und zur Bereitstellung wird eine einzige Assembly im lokalen /BIN-Verzeichnis generiert. Mit WAP ist es auch viel leichter, schrittweise die partielle Klasse des in ASP-NET 2.0 eingeführten Codebehind-Modells zu übernehmen, weil jetzt beim Öffnen eines Visual Studio .NET 2003-Projekts nur SLN- und CSPROJ- (oder VBPROJ-) Dateien bei der Konvertierung geändert werden. Sie können dann jede Datei und ihre Codebehind-Klasse unabhängig von anderen Dateien im Projekt zum neuen partiellen Klassenmodell konvertieren (Klicken Sie im Solution Explorer mit der rechten Maustaste auf die Datei, und wählen Sie „Convert to Web Application“ [In Webanwendung konvertieren]), oder weiterhin das alte Modell verwenden. Dieses Vorgehen unterscheidet sich von der Konvertierung eines Visual Studio .NET 2003-Webprojekts zum Websitemodell, wo alle Dateien auf einmal konvertiert werden und eine schrittweise Anpassung nicht unterstützt wird.
Schließlich gibt es einen neuen Projekttyp „Webbereitstellungsprojekte“ (Hauptthema dieses Artikels), mit dem die Einführung vieler zusätzlicher Bereitstellungsoptionen für Websiteprojekte und Webanwendungsprojekte möglich ist. Webbereitstellungsprojekte ergänzen die Bereitstellungsoptionen bei Websiteanwendungen und Webanwendungsprojekten und machen es möglich, praktisch jedes Bereitstellungsszenario auf einfache und erweiterbare Weise zu implementieren. Um genau zu verstehen, was das Neue an diesem Projekttyp ist, befassen wir uns kurz mit den Möglichkeiten, die wir bis jetzt ohne Webbreitstellungsprojekte hatten.

Bereitstellung in ASP.NET 2.0
Wenn Sie eine Anwendung mit dem Websitemodell erstellen, haben Sie die Möglichkeit, die Site zur Bereitstellung vorzukompilieren. Sie können auf das Dienstprogramm zur Vorkompilierung über das Menü zum Erstellen | Veröffentlichen in Visual Studio 2005 oder direkt über das Befehlszeilenprogramm „spnet_compiler.exe“ zugreifen. Abbildung 1 zeigt die Schnittstelle zu diesem Tool in Visual Studio.
Abbildung 1 Websitedienstprogramm veröffentlichen (Klicken Sie zum Vergrößern auf das Bild)
Die erste Entscheidung, die Sie bei der Verwendung des Veröffentlichungsdienstprogramms treffen müssen, ist, ob Ihre AS*X-Dateien nach der Bereitstellung aktualisierbar sein sollen (siehe Option „Aktualisierbarkeit dieser vorkompilierten Site zulassen“ des -u-Schalters im Befehlszeilenprogramm „aspnet_compiler.exe“) Diese Entscheidung hängt davon ab, ob Sie nach der Bereitstellung kleine Änderungen an Ihren Seiten vornehmen möchten, ohne den gesamten Bereitstellungsprozess erneut durchführen zu müssen. Tatsächlich kann es von Vorteil sein, ausdrücklich Änderungen an den bereitgestellten Seiten zu untersagen und für Änderungen den Standardbereitstellungs- (und hoffentlich Test-)prozess erforderlich zu machen. In diesem Fall sollten Sie die Site als nicht aktualisierbar veröffentlichen.
Wenn eine Site als nicht aktualisierbar veröffentlicht wird, ist es möglich, alle AS*X-Dateien vollständig zu entfernen und nur binäre Assemblys (sowie Konfigurationsdateien und statischen Inhalt) zu veröffentlichen. Ohne die physischen Dateien an der richtigen Stelle, ist es jedoch für ASP.NET unmöglich, festzustellen, welche Klassen für welche Endpunktanforderungen zu verwenden sind. Wenn z. B. eine Anforderung für Page1.aspx in Ihrer Anwendung ankommt, und Sie eine nicht aktualisierbare binäre Bereitstellung verwendet haben, kann es sehr gut sein, dass keine Datei „Page1.aspx“ auf dem Datenträger existiert und die bestehenden Konfigurationsdateien keinen Hinweis darauf enthalten, welche Klasse in der Sammlung von Assemblys im /BIN-Verzeichnis als Handler für diese Anforderung fungieren soll. Um dies zu umgehen, wird beim Kompilierungsprozess auch eine Sammlung von .COMPILED-Dateien generiert, die Endpunkt-zu-Typ-Zuordnungen und Dateiabhängigkeitsinformationen in einfachem XML-Format enthalten. Diese Dateien müssen zusammen mit den binären Assemblys im /BIN-Verzeichnis der bereitgestellten Site veröffentlicht werden. Ein Beispiel: Wenn Sie eine Seite namens „Page1.aspx“ in Ihrer Anwendung haben, generiert das Dienstprogramm „aspnet_compiler.exe“ eine Datei „page1.aspx.cdcab7d2.compiled“ (mit veränderlichem Hashcode), die folgendes XML enthält:
<?xml version="1.0" encoding="utf-8"?>
<preserve resultType="3"  
          virtualPath="/SampleWebSite/Page1.aspx" 
          hash="8a8da6c5a" filehash="42c4a74221152888" 
          flags="110000" assembly="App_Web_aq9bt8mj" 
          type="ASP.page1_aspx">
  <filedeps>        
    <filedep name="/SampleWebSite/Page1.aspx" />
    <filedep name="/SampleWebSite/Page1.aspx.cs" />
  </filedeps>
</preserve>
Die andere wichtige Entscheidung, die Sie beim Veröffentlichen einer Website mit diesem Dienstprogramm treffen müssen, betrifft die Granularität der Verpackung der generierten Assemblys. Sie können entweder eine getrennte Assembly für jedes Verzeichnis in Ihrer Site erstellen, oder eine getrennte Assembly für jede kompilierbare Datei in Ihrer Site (ASPX, ASCX, ASAX und so weiter), indem Sie die Option „Feste Benennungen und Assemblys mit einzelnen Seiten verwenden“ (oder „-fixednames“ im Befehlszeilenprogramm „aspnet_compiler.exe“) aktivieren. Diese Entscheidung wirkt nur auf den ersten Blick ganz einfach. Jede Option kann gewisse Probleme mit sich bringen. Wenn Sie die Option „-fixednames“ nicht verwenden, wird jedes Mal, wenn Sie Ihre Anwendung veröffentlichen, ein komplett neuer Satz Assemblys generiert, mit völlig anderen Namen als bei der letzten veröffentlichten Version. Das bedeutet, dass die Bereitstellung kniffliger ist, weil Sie nicht vergessen dürfen, alle vorher veröffentlichten Assemblys auf dem laufenden Liveserver zu löschen, bevor die neuen Assemblys bereitgestellt werden, da sonst Definitionsfehler durch redundante Klassen bei der nächsten Anforderung generiert werden. Mit der -fixednames-Option wird dieses Problem beseitigt, da jede Datei einer eindeutig benannten Assembly zugewiesen wird, die von einer Kompilierung zur nächsten unverändert bleibt. Wenn Sie jedoch eine große Site haben, kann die Generierung von getrennten Assemblys für jede Seite, jedes Steuerelement und jede Masterseite bedeuten, dass Hunderte von Assemblys verwaltet und veröffentlicht werden müssen. Wie Sie noch sehen werden, wird dieses Problem hinsichtlich der Granularität von Assemblys bei der Bereitstellung von Webbereitstellungsprojekten viel besser gelöst.
Sie können Assemblys auch per Signatur in den Kompilierungsprozess einführen, um Assemblys mit starkem Namen und Versionsangabe zu erstellen, die bei Bedarf im globalen Assemblycache (GAC) bereitgestellt werden können. Sie können den generierten Assemblys mit der Option „-aptca“ das Assemblyebenenattribut „AllowPartiallyTrustedCallers“ zuweisen, das für eine Bereitstellung von Assemblys im GAC oder beim Einsatz von ASP.NET mit einem niedrigen oder mittleren Vertrauenslevel nötig wäre. (Bedenken Sie, dass dieses Attribut nur auf Assemblys angewendet werden sollte, die nachweislich keine Anfälligkeiten hinsichtlich der Sicherheit zeigen, da sie sonst einen Angriff hervorrufen könnten.)
Ein weiterer Punkt bei der Veröffentlichung Ihrer Site ist, dass bei der Auswahl eines Webanwendungsprojekts anstelle des Websitemodells das Dialogfeld zum Erstellen | Veröffentlichen anders aussieht (siehe Abbildung 2). Bei Webanwendungsprojekten wird angenommen, dass Sie die Anwendung als aktualisierbare AS*X-Dateien und vorkompilierte Quelldateien veröffentlichen möchten (nach demselben Modell, das in der Entwicklung verwendet wird), deshalb sind die Optionen für rein binäre Bereitstellung nicht verfügbar. Dieses Dienstprogramm ist eigentlich dem in Websites verfügbaren Dienstprogramm „Website kopieren“ ähnlicher als dem Dienstprogramm „Website veröffentlichen“, da es Dateien kopiert, die im Standardbuildprozess erstellt werden.
Abbildung 2 Veröffentlichen von Internetdienstprogrammen für Webanwendungsprojekte (Klicken Sie zum Vergrößern auf das Bild)
Technisch gesehen können Sie weiterhin eine rein binäre (nicht aktualisierbare) Bereitstellung vornehmen, auch wenn Sie Webanwendungsprojekte verwenden. Wenn man es genau betrachtet, ist die Ausgabe des Builds eines WAP eine gültige Website, die Sie dann an das Dienstprogramm „aspnet_compiler.exe“ übergeben können, um eine binäre Bereitstellung zu generieren. Sie können es nur von der Visual Studio 2005-Schnittstelle nicht aufrufen, was glücklicherweise durch Webbereitstellungsprojekte korrigiert wird.

Webbereitstellungsprojekte
Was fehlt also bei den vorhandenen Kompilierungs- und Bereitstellungsoptionen, die wir bisher vorgestellt haben? Hauptsächlich zwei Dinge: Die Möglichkeit, die Benennung der Assemblys zu steuern, insbesondere für Bereitstellungszwecke, und die Möglichkeit, alle Ausgabeassemblys für eine vereinfachte Bereitstellung in einer einzigen Assembly zu vereinen. Webbereitstellungsprojekte lösen beide Probleme. Und was vielleicht noch wichtiger ist: Sie gleichen außerdem einige Ecken und Kanten der bisherigen Bereitstellung aus, die bei Websiteanwendungen und Webanwendungsprojekten vorhanden waren.
Im Grunde stellen Webbereitstellungsprojekte (zum Download verfügbar unter: msdn2.microsoft.com/aa336619.aspx) nur eine andere Projektart dar, die Sie zu Ihrer Lösung hinzufügen. Wie alle Visual Studio-Projektdateien sind Webbereitstellungsprojekte MSBuild-Skripts, die direkt in der IDE kompiliert oder von der Befehlszeile aus ausgeführt werden können. Anstatt eine Sammlung von Quellcodedateien für die Kompilierung anzugeben, enthalten Webbereitstellungsprojekte Buildbefehle zur Kompilierung und Verpackung von Websites (oder Webanwendungsprojekten). Das bedeutet, dass sie (unter anderem) das Dienstprogramm „aspnet_compiler.exe“ und aufrufen, um die Bereitstellung einer bestimmten Webanwendung zu erstellen. Webbereitstellungsprojekte werden als Visual Studio-Add-In-Paket geliefert, das ein leicht zu bedienendes Menüelement zum Einfügen neuer Projekte und einen vollständigen Satz Eigenschaftenseiten umfasst, mit dem alle verfügbaren Einstellungen gesteuert werden können. Um einer vorhandenen Anwendung ein Webbereitstellungsprojekt hinzuzufügen, klicken Sie mit der rechten Maustaste auf eine vorhandene Website (oder ein Webanwendungsprojekt), und wählen Sie das Element zum Hinzufügen von Webbereitstellungsprojekten aus (siehe Abbildung 3). Dadurch wird Ihrer Lösung eine neue WDPROJ-Datei hinzugefügt, die ein MSBuild-Skript enthält, mit dem eine Bereitstellung der Anwendung generiert wird, in der Sie sie erstellt haben.
Abbildung 3 Hinzufügen von Webbereitstellungsprojekten 
Abbildung 3a   
Abbildung 3b   (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 3c   
Sobald das Webbereitstellungsprojekt Teil Ihrer Lösung ist, können Sie auf die Eigenschaftenseiten der Projektdatei zugreifen, um genau zu steuern, welche Aufgaben das Projekt ausführt (siehe Abbildung 4). Die Standardeinstellung für ein neues Bereitstellungsprojekt ist, die Anwendung in aktualisierbarer Form, mit allen intakten AS*X-Dateien, bereitzustellen, und die Quelldateien in eine einzige Assembly zu kompilieren, die im /BIN-Verzeichnis der höchsten Ebene bereitgestellt wird. Diese Bereitstellungsprojekte funktionieren auf gleiche Weise, egal ob in der Quellanwendung das Websitemodell oder das Webanwendungsprojekt-Modell verwendet wird. Das bedeutet, dass Sie nun die Wahl zwischen den beiden Entwicklungsmodellen haben, ohne bei den Bereitstellungsoptionen eingeschränkt zu werden. Eine der wichtigsten Funktionen von Webbereitstellungsprojekten ist die Möglichkeit, die Bereitstellung als rein binär (nicht aktualisierbar) in Form einer einzigen Assembly zu konfigurieren, deren Namen Sie selbst auswählen können. Bei Verwendung dieses Bereitstellungsmodells können Sie Ihre gesamte Site aktualisieren, indem Sie eine einzige Assembly in das /BIN-Verzeichnis Ihrer Livesite verschieben. Sie müssen vor der Bereitstellung nicht mehr an das Löschen bestehender Assemblys denken oder sich mit einer teilweise bereitgestellten, Fehler verursachenden Site befassen. Es ist weiterhin notwendig, die COMPILED-Dateien für die Zuordnung von Endpunkten bereitzustellen, aber diese Dateien ändern sich nur, wenn Sie Seiten in Ihrer Site hinzufügen, löschen oder verschieben.
Abbildung 4 Eigenschaftenseite von Webbereitstellungsprojekten (Klicken Sie zum Vergrößern auf das Bild)
Webbereitstellungsprojekte erhöhen die Flexibilität bei der Bereitstellung und geben Ihnen die Möglichkeit, Entscheidungen hinsichtlich der Verpackung und Bereitstellung unabhängig von der Art der Entwicklung Ihrer Webanwendungen zu treffen. Diese Unabhängigkeit zwischen Entwicklung und Bereitstellung wurde teilweise in der ursprünglichen Veröffentlichung von ASP.NET 2.0 mit dem Dienstprogramm „aspnet_compiler.exe“ erreicht, aber aufgrund der Einschränkungen bei der tatsächlichen Bereitstellung nie völlig realisiert. Mit Webbereitstellungsprojekten ist die Trennung zwischen Entwicklung und Bereitstellung jetzt vollständig, und Ihre Entscheidung hinsichtlich der Entwicklungsweise Ihrer Anwendungen wirkt sich nun nicht mehr auf Ihre Bereitstellungsmöglichkeiten aus.

Zusammenführen von Assemblys
Ein großer Teil der Funktionen von Webbereitstellungsprojekten sind nur neu verpackte, bereits bestehende Dienstprogramme, die über MSBuild-Tasks und eine neue Schnittstelle zur Verfügung gestellt werden. Es gibt aber auch eine Reihe ganz neuer Funktionen. Die faszinierendste davon ist die Möglichkeit zum Zusammenführen von Assemblys.
Wenn Sie Webbereitstellungsprojekte installieren, werden Sie eine EXE-Datei namens „aspnet_merge.exe“ im Installationsverzeichnis finden (standardmäßig %PROGRAMFILES%\MSBuild\Microsoft\WebDeployment\v8.0). Mit dieser EXE-Datei können Sie die ausgegebenen Assemblys einer vorkompilierten Site in einer einzigen Assembly zusammenführen. Dies ist das Dienstprogramm, das in Ihr Buildskript eingefügt wird, wenn Sie die Option zum Zusammenführen in einem Webbereitstellungsprojekt wählen. Sehen wir uns als Beispiel für die Möglichkeiten, die dieses Dienstprogramm bietet, in Abbildung 5 die Ausgabe einer vorkompilierten Website an, die ohne Schalter für Aktualisierbarkeit ausgeführt wurde. Die Quellanwendung für diese Ausgabe enthielt zwei Unterverzeichnisse, eine Datei „global.asax“ im obersten Verzeichnis, eine in App_Code definierte Klasse und ein Steuerelement. Das Endergebnis der Kompilierung sind fünf verschiedene Assemblys und eine Sammlung von COMPILED-Dateien. Wenn Sie das Dienstprogramm „aspnet_merge.exe“ mit dem -o-Schalter auf dieses Verzeichnis anwenden, um die Ausgabe einer einzigen Assembly anzufordern (siehe Abbildung 5 unten), ist das Ergebnis eine viel einfacher zu verwaltende, einzelne Assembly, deren Namen Sie bestimmen können.
Abbildung 5a Verwenden des Dienstprogramms „aspnet_merge.exe“ (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 5b(Klicken Sie zum Vergrößern auf das Bild)
Obwohl das in Webbereitstellungsprojekten integrierte Dienstprogramm „aspnet_merge.exe“ und die zugehörige MSBuild-Task neu sind, gibt es die zugrunde liegende Technologie für das Zusammenführen von Assemblys tatsächlich schon seit es in Microsoft® .NET Framework 1.1 in Form eines bei Microsoft Research unter dem Namen „ILMerge“ bekannten Dienstprogramms zur Verfügung gestellt wurde. Die neueste Version ist unter research.microsoft.com/~mbarnett/ILMerge.aspx zum Download verfügbar. Dieses Dienstprogramm ist direkt in aspnet_merge.exe integriert und übernimmt die meiste Arbeit beim Zusammenführen von Assemblys. Genau betrachtet, ist das Zusammenführen von Assemblys nämlich eine recht komplizierte Angelegenheit. Sie müssen Signatur, Versionierung sowie weitere Attribute auf Assemblyebene, eingebettete Ressourcen und die XML-Dokumentation berücksichtigen und auch die Details wie kollidierende Typnamen usw. verwalten. Das Dienstprogramm „ILMerge“ verwaltet all diese Details für Sie und gibt Ihnen über Schalter die Möglichkeit, verschiedene Prozessentscheidungen zu steuern. Es ermöglicht es Ihnen außerdem, zu Verpackungszwecken EXE-Assemblys zu DLL-Assemblys zu transformieren. Ein Beispiel: Nehmen wir an, Sie haben drei Assemblys, a.dll, b.dll und c.exe, die Sie in eine einzige Bibliothekassembly zusammenführen möchten. Sofern es keine Konflikte bei Typnamen gibt, generiert die folgende Befehlszeile eine neue Bibliothek „d.dll“ mit allen Typen, die in a.dll, b.dll und c.exe definiert wurden:
ilmerge.exe /t:library /ndebug /out:d.dll a.dll b.dll c.exe

Austauschbare Konfigurationsdateien
Die zweite vollständig neue Funktion, die in Webbereitstellungsprojekten enthalten ist, ist die Möglichkeit zur Erstellung austauschbarer Konfigurationsdateien. Beim Bereitstellen von Webanwendungen ist es häufig problematisch, die Konfigurationsdateiunterschiede zwischen Entwicklung und Bereitstellung zu verwalten. Sie können z. B. eine lokale Testdatenbank für den Betrieb Ihrer Site nutzen, eine weitere für einen Stagingserver und eine dritte für den Liveserver. Wenn Sie Ihre Verbindungszeichenfolgen in der Datei „web.config“ speichern (normalerweise im Abschnitt „connectionStrings“), ist es wichtig, diese Zeichenfolgen bearbeiten zu können, wenn die Anwendung an einen Staging- oder Produktionsserver übertragen wird. Webbereitstellungsprojekte bieten mit einer neuen MSBuild-Task namens „ReplaceConfigSections“ eine saubere Lösung für dieses Problem.
Diese Task ermöglicht es Ihnen, unabhängige Dateien anzugeben, in denen der Inhalt eines speziellen Konfigurationsabschnitts entsprechend der Lösungskonfiguration gespeichert wird. Sie könnten z. B. eine Datei „debugconnectionstrings.config“ erstellen, in der die Debugversion unseres Konfigurationsabschnitts „connectionStrings“ gespeichert wird. Dies sähe dann so aus:
<connectionStrings>
    <add connectionString="server=localhost;database=sales;
                           trusted_connection=yes" name="sales_dsn"/>
</connectionStrings>
Auf ähnliche Weise würden Sie dann getrennte Dateien für jede der definierten Lösungskonfigurationen erstellen (Veröffentlichung, Staging und so weiter) und sie mit den gewünschten Verbindungszeichenfolgen für die jeweiligen Bereitstellungsumgebungen auffüllen. Für die Veröffentlichungskonfiguration könnten Sie die Datei „releaseconnectionstrings.config“ nennen und sie folgendermaßen auffüllen:
<connectionStrings>
    <add connectionString="server=livedbserver;database=sales;
                           trusted_connection=yes" 
                           name="sales_dsn"/>
</connectionStrings>
Als nächstes würden Sie das von Webbereitstellungsprojekten hinzugefügte MSBuild-Skript so konfigurieren, dass es beschreibt, welche Konfigurationsabschnitte in der Hauptdatei „web.config“ ersetzt werden sollen, und aus welcher Quelle der Ersatz stammen soll. Sie könnten das Skript manuell ändern, aber es gibt auch eine nette Schnittstelle, die über die Eigenschaftenseiten des Buildskripts in Visual Studio zur Verfügung steht und dies für Sie übernimmt (siehe Abbildung 6). In diesem Fall legen Sie die Eigenschaften für die Konfiguration der Debuglösung fest. Aktivieren Sie dazu die Abschnittsersetzungsoption für die Datei „web.config“, und geben Sie an, welcher Abschnitt ersetzt werden soll und aus welcher Datei die neuen Inhalte stammen sollen.
connectionStrings=debugconnectionstrings.config
Abbildung 6 Eigenschaftenseite zum Festlegen der Konfigurationsdatei-Abschnittsersetzung (Klicken Sie zum Vergrößern auf das Bild)
Verwenden Sie dieselbe Dialogseite, um die Ersetzung der Konfiguration der Veröffentlichungslösung (und weiterer definierter Konfigurationen) durch die jeweiligen Dateien festzulegen.
Wenn Sie dann das Buildskript ausführen, extrahiert die Task „ReplaceConfigSections“ den entsprechenden Inhalt aus den zugeordneten Konfigurationsdateien und ersetzt den Inhalt des jeweiligen Konfigurationsabschnitts. Eine neue web.config-Datei wird erstellt und an das Bereitstellungsverzeichnis übertragen. Die Konfigurationsdatei-Ersetzungsfunktion ermöglicht ein übersichtliches Pflegen der Konfigurationsunterschiede von Bereitstellungsumgebungen mithilfe von Textdateien, die unter der Quellcodeverwaltung versioniert werden können. So müssen Sie bei der Bereitstellung nicht mehr daran denken, die Verbindungszeichenfolge zu ändern. Es sollte betont werden, dass dieses Feature für alle Abschnitte der Konfigurationsdatei funktioniert, sogar für benutzerdefinierte Abschnitte, sodass Sie Unterschiede in anderen Konfigurationsabschnitten (z. B. appSettings) ebenso mit dieser Buildtask angeben können.

Erstellen wiederverwendbarer Benutzersteuerelemente
Es gibt eine interessante Nebenanwendung von Webbereitstellungsprojekten, die ein Problem löst, das ASP.NET-Entwickler seit Jahren plagt, nämlich wie sich wiederverwendbare Benutzersteuerelemente erstellen lassen, die über verschiedene Anwendungen hinweg verwendet werden können. Benutzersteuerelemente sind im Grunde nur zusammengestellte benutzerdefinierte Steuerelemente, deren untergeordnete Steuerelemente in einer ASCX-Datei angelegt sind. Die Möglichkeit, den Designer für das Anlegen von Steuerelementen und das Hinzufügen von Handlern zu verwenden, ist ein großer Vorteil für viele Entwickler, da sie fast identisch mit dem Erstellen einer Seite ist, mit der einen Ausnahme, dass die resultierende ASCX-Datei als Steuerelement in jede beliebige Seite eingefügt werden kann. Der Nachteil dabei war immer, dass sich die physische ASCX-Datei im Verzeichnis der Anwendung befinden muss, damit das Element tatsächlich verwendet werden kann. Verfahren für die Nutzbarmachung von ASCX-Steuerelementen in verschiedenen Anwendungen existieren zwar, aber sie erfordern normalerweise z. B. die Erstellung gemeinsamer virtueller Verzeichnisse für mehrere Anwendungen oder das Abfangen temporärer Assemblys, die zur Anforderungszeit von ASP.NET generiert werden, und diese Verfahren waren nie ideal.
Die Einführung des Dienstprogramms „aspnet_compiler.exe“ in Version 2.0 hat uns einer befriedigenden Lösung deutlich näher gebracht. Mit dem Compiler können Sie eine Website erstellen, die nur aus Benutzersteuerelementen besteht, diese in nicht aktualisierbarem Modus veröffentlichen und den Compiler dazu nutzen, wiederverwendbare Assemblys zu generieren. Sobald Sie die resultierenden Assemblys haben, ist eine Bereitstellung auf allen gewünschten Webanwendungen möglich, und Sie können auf das Benutzersteuerelement wie auf ein benutzerdefiniertes Steuerelement verweisen (nicht wie bei ASCX-Dateien mithilfe des Attributs „src“). Der einzige Nachteil dieses Verfahrens ist, dass Sie entweder die zufällig benannte Assembly aus dem Kompilierungsprozess annehmen müssen oder im Compiler die Option „fixednames“ wählen müssen, um eine fest benannte Assembly für jede Masterseite der Site zu generieren (eine einzige Assembly für die gesamte Sammlung ist nicht möglich).
Webbereitstellungsprojekte sind der letzte Schritt bei der Erstellung vollständig wiederverwendbarer Benutzersteuerelement-Assemblys. Sie können der Website, die ausschließlich aus Benutzersteuerelementen besteht, ein Webbereitstellungsprojekt hinzufügen, um eine einzige Ausgabeassembly mit frei wählbarem Namen zu erstellen. Es ist sogar ganz einfach, eine signierte Assembly zu erstellen, die dem GAC zur gemeinsamen Verwendung der Steuerelemente über mehrere Anwendungen bereitgestellt wird, ohne dass sie in jedem /BIN-Verzeichnis erneut bereit gestellt werden muss.

Schlussbemerkung
Die Veröffentlichung von Webbereitstellungsprojekten vervollständigt den Toolsatz für die Bereitstellung von ASP.NET-Anwendungen auf sehr zufrieden stellende Weise. Anwendungen können nun auf jede beliebige Weise bereitgestellt werden, entweder nur als Quellcode oder komplett binär, und das bei vollständiger Kontrolle über Generierung, Verpackung und Benennung der binären Assemblys. Außerdem beinhalten Webbereitstellungsprojekte eine Lösung für das Ersetzen von Abschnitten Ihrer Konfigurationsdateien basierend auf Ihrem Zielbuild und lösen außerdem das Problem der gemeinsamen Nutzung von Benutzersteuerelementen. Jeder, der ASP.NET-Anwendungen entwickelt und bereitstellt, findet an Webbereitstellungsprojekten mit Sicherheit einen Aspekt, der ihn dazu bewegt, sie sofort zu verwenden.

Senden Sie Fragen und Kommentare in englischer Sprache an Fritz Onion unter  xtrmasp@microsoft.com.


Fritz Onionist Mitgründer von Pluralsight, einem Microsoft .NET-Schulungsanbieter, und leitet dort Schulungen zur Webentwicklung. Er ist Autor von Essential ASP.NET (Addison Wesley 2003) und Essential ASP.NET 2.0 (Addison Wesley 2006). Sie erreichen ihn unter pluralsight.com/fritz.

Page view tracker