Vorkompilieren Ihrer Website (C#)

von Scott Mitchell

Visual Studio bietet ASP.NET Entwicklern zwei Arten von Projekten: Web Application Projects (WAPs) und Web Site Projects (WSPs). Einer der wichtigsten Unterschiede zwischen den beiden Projekttypen besteht darin, dass für WAPs der Code vor der Bereitstellung explizit kompiliert werden muss, während der Code in einem WSP automatisch auf dem Webserver kompiliert werden kann. Es ist jedoch möglich, einen WSP vor der Bereitstellung vorzukompilieren. In diesem Tutorial werden die Vorteile der Vorkompilierung untersucht und gezeigt, wie sie eine Website in Visual Studio und über die Befehlszeile vorkompilieren.

Einführung

Visual Studio bietet ASP.NET Entwicklern zwei verschiedene Projekttypen: Web Application Projects (WAP) und Web Site Projects (WSP). Einer der wichtigsten Unterschiede zwischen diesen Projekttypen besteht darin, dass WAPs eine explizite Kompilierung erfordern, während WSPs standardmäßig die automatische Kompilierung verwenden. Mit WAPs kompilieren Sie den Code der Webanwendung in eine einzelne Assembly, die im Ordner der Website Bin erstellt wird. Die Bereitstellung beinhaltet das Kopieren des Markupinhalts (der .aspx.ascx- und .master der Dateien) im Projekt zusammen mit der Assembly im Bin Ordner. Die CodeBehind-Klassendateien selbst müssen nicht bereitgestellt werden. Andererseits stellen Sie WSPs bereit, indem Sie sowohl die Markupseiten als auch die entsprechenden CodeBehind-Klassen in die Produktionsumgebung kopieren. Die CodeBehind-Klassen werden bei Bedarf auf dem Webserver kompiliert.

Hinweis

Weitere Informationen zu den Unterschieden zwischen den Projektmodellen, der expliziten und automatischen Kompilierung und den Auswirkungen des Kompilierungsmodells auf die Bereitstellung des Kompilierungsmodells finden Sie im Abschnitt "Explizite Kompilierung im Vergleich zur automatischen Kompilierung" im Tutorial Zur Bestimmung, welche Dateien bereitgestellt werden müssen.

Die Automatische Kompilierungsoption ist einfach zu verwenden. Es gibt keinen expliziten Kompilierungsschritt, und es müssen nur die Dateien bereitgestellt werden, die geändert wurden, während die explizite Kompilierung die Bereitstellung der geänderten Markupseiten und der gerade kompilierten Assembly erfordert. Die automatische Bereitstellung hat jedoch zwei potenzielle Nachteile:

• Da die Seiten beim ersten Besuch automatisch kompiliert werden müssen, kann es nach der Bereitstellung zu einer kurzen, aber spürbaren Verzögerung kommen, wenn eine ASP.NET Seite zum ersten Mal angefordert wird.
• Die automatische Kompilierung erfordert, dass sowohl das deklarative Markup als auch der Quellcode auf dem Webserver vorhanden sind. Dies kann eine unattraktive Option sein, wenn Sie die Webanwendung an Kunden verkaufen möchten, die sie auf ihren Webservern installieren.

Wenn es sich bei einer der beiden oben genannten Mängel um Deal Breaker handelt, können Sie entweder zum WAP-Modell wechseln oder den WSP vor der Bereitstellung vorkompilieren . In diesem Tutorial werden die Vorkompilierungsoptionen untersucht, die sich am besten für eine gehostete Website eignen, und es wird der Vorkompilierungsprozess und die Bereitstellung einer vorkompilierten Website beschrieben.

Übersicht über ASP.NET Codegenerierung und -kompilierung

Bevor wir uns die verfügbaren Vorkompilierungsoptionen ansehen, gehen wir zunächst auf die Codegenerierung und -kompilierung ein, die auftritt, wenn eine ASP.NET Seite zum ersten Mal seit ihrer Erstellung oder letzten Aktualisierung angefordert wird. Wie Sie wissen, bestehen ASP.NET Seiten aus zwei Teilen: deklaratives Markup in der .aspx Datei und einem Quellcodeteil, normalerweise in einer separaten CodeBehind-Klassendatei (.aspx.cs). Welche Schritte von der Runtime ausgeführt werden, wenn eine ASP.NET Seite angefordert wird, hängt vom Kompilierungsmodell der Anwendung ab.

Bei WAPs muss der Quellcode der Seiten vor der Bereitstellung explizit in eine einzelne Assembly kompiliert werden. Während der Bereitstellung werden diese Assembly und die verschiedenen Markupseiten in die Produktionsumgebung kopiert. Wenn eine Anforderung beim Webserver für eine ASP.NET Seite eingeht, erstellt die Runtime eine Instanz der CodeBehind-Klasse der Seite und ruft ihre ProcessRequest Methode auf, die den Seitenlebenszyklus startet und letztendlich den Inhalt der Seite generiert, der an den Anforderer zurückgegeben wird. Die Runtime kann mit der Code Behind-Klasse der ASP.NET Seite arbeiten, da die Code-Behind-Klasse bereits vor der Bereitstellung in eine Assembly kompiliert wurde.

Bei WSPs und der automatischen Kompilierung gibt es vor der Bereitstellung keinen expliziten Kompilierungsschritt. Stattdessen müssen bei der Bereitstellung sowohl der deklarative als auch der Quellcodeinhalt in die Produktionsumgebung kopiert werden. Wenn eine Anforderung für eine ASP.NET Seite zum ersten Mal seit der Erstellung oder letzten Aktualisierung der Seite beim Webserver eingeht, muss die Runtime zuerst die CodeBehind-Klasse in eine Assembly kompilieren. Diese kompilierte Assembly wird im Ordner %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Filesgespeichert, obwohl der Speicherort dieses Ordners über das <compilation tempDirectory="" /> -Element von <system.web>angepasst werden kann, normalerweise in Web.config. Da die Assembly auf dem Datenträger gespeichert wird, muss sie nicht bei nachfolgenden Anforderungen auf derselben Seite neu kompiliert werden.

Hinweis

Wie zu erwarten, gibt es eine leichte Verzögerung beim erstmaligen Anfordern einer Seite (oder zum ersten Mal seit ihrer Änderung) auf einer Website, die die automatische Kompilierung verwendet, da es einen Moment dauert, bis der Server den Code der Seite kompiliert und die resultierende Assembly auf dem Datenträger speichert.

Kurz gesagt, bei der expliziten Kompilierung müssen Sie den Quellcode der Website vor der Bereitstellung kompilieren, sodass die Runtime nicht diesen Schritt ausführen muss. Bei der automatischen Kompilierung übernimmt die Runtime die Kompilierung des Quellcodes der Seiten, jedoch mit geringfügigen Initialisierungskosten für den ersten Besuch der Seite seit ihrer Erstellung oder letzten Aktualisierung.

Aber was ist mit dem deklarativen Teil ASP.NET Seiten (die .aspx Datei)? Es ist offensichtlich, dass zwischen den .aspx Dateien und dem Code in ihren CodeBehind-Klassen eine Beziehung besteht, da auf die im deklarativen Markup definierten Websteuerelemente im Code zugegriffen werden kann. Es ist auch offensichtlich, dass der Inhalt in den .aspx Dateien das gerenderte Markup, das von der Seite generiert wird, erheblich beeinflusst. Wie funktioniert die Laufzeit also mit der in der .aspx Datei definierten Syntax für Text, HTML und Websteuerelement, um den gerenderten Inhalt der angeforderten Seite zu generieren?

Ich möchte nicht zu wenig auf die Implementierungsdetails auf niedriger Ebene zurückverfolgen, die zwischen WAPs und WSPs variieren, aber kurz gesagt generiert die Runtime automatisch eine Klassendatei, die die verschiedenen Websteuerelemente als geschützte Member und Methoden enthält. Diese generierte Datei wird als partielle Klasse in der entsprechenden CodeBehind-Klasse implementiert. (Partielle Klassen ermöglichen es, dass der Inhalt einer einzelnen Klasse auf mehrere Dateien verteilt wird.) Daher wird die CodeBehind-Klasse an zwei Stellen definiert: in der .aspx.cs datei, die Sie erstellen, und in dieser automatisch generierten Klasse, die von der Runtime erstellt wurde. Diese automatisch generierte Klasse wird im %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files Ordner gespeichert.

Wichtig dabei ist, dass für eine ASP.NET Seite, die von der Runtime gerendert werden soll, sowohl der deklarative als auch der Quellcodeteil in eine Assembly kompiliert werden müssen. Bei WAPs wird der Quellcode vor der Bereitstellung explizit in eine Assembly kompiliert, aber das deklarative Markup muss weiterhin in Code konvertiert und von der Runtime auf dem Webserver kompiliert werden. Wenn WSPs die automatische Kompilierung verwenden, müssen sowohl der Quellcode als auch das deklarative Markup vom Webserver kompiliert werden.

Es ist möglich, die explizite Kompilierung mit dem WSP-Modell zu verwenden. Sie können den Quellcodeteil explizit kompilieren, z. B. mit dem WAP-Modell. Darüber hinaus können Sie das deklarative Markup auch kompilieren.

Vorkompilierungsoptionen

Die .NET Framework wird mit einem ASP.NET Kompilierungstool (aspnet_compiler.exe) ausgeliefert, mit dem Sie den Quellcode (und sogar den Inhalt) einer ASP.NET Anwendung kompilieren können, die mit dem WSP-Modell erstellt wurde. Dieses Tool wurde mit der .NET Framework Version 2.0 veröffentlicht und befindet sich im %WINDIR%\Microsoft.NET\Framework\v2.0.50727 Ordner. Es kann über die Befehlszeile verwendet oder in Visual Studio über die Option Website veröffentlichen des Menüs Erstellen gestartet werden.

Das Kompilierungstool bietet zwei allgemeine Formen der Kompilierung: direkte Vorkompilierung und Vorkompilierung für die Bereitstellung. Bei der direkten Vorkompilierung führen Sie das aspnet_compiler.exe Tool über die Befehlszeile aus und geben den Pfad zum virtuellen Verzeichnis oder physischen Pfad einer Website an, die sich auf Ihrem Computer befindet. Das Kompilierungstool kompiliert dann jede ASP.NET Seite im Projekt und speichert die kompilierte Version im %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files Ordner so, als ob die Seiten jeweils zum ersten Mal über einen Browser aufgerufen wurden. Die direkte Vorkompilierung kann die erste Anforderung an neu bereitgestellte ASP.NET Seiten auf Ihrer Website beschleunigen, da die Laufzeit diesen Schritt nicht mehr ausführen muss. Die direkte Vorkompilierung ist jedoch für die meisten gehosteten Websites nicht nützlich, da sie erfordert, dass Sie Programme über die Befehlszeile des Webservers ausführen können. In Shared Hosting-Umgebungen ist diese Zugriffsebene nicht zulässig.

Hinweis

Weitere Informationen zur direkten Vorkompilierung finden Sie unter Vorgehensweise: Vorkompilieren ASP.NET Websites und Vorkompilierung in ASP.NET 2.0.

Anstatt die Seiten auf der Website in den Temporary ASP.NET Files Ordner zu kompilieren, kompiliert die Vorkompilierung für die Bereitstellung die Seiten in ein Verzeichnis Ihrer Wahl und in einem Format, das in der Produktionsumgebung bereitgestellt werden kann.

Es gibt zwei Varianten der Vorkompilierung für die Bereitstellung, die wir in diesem Tutorial untersuchen: Vorkompilierung mit einer aktualisierbaren Benutzeroberfläche und Vorkompilierung mit einer nicht aktualisierbaren Benutzeroberfläche. Bei der Vorkompilierung mit einer aktualisierbaren Benutzeroberfläche verbleibt das deklarative Markup in den .aspxDateien , .ascxund .master , sodass entwickler das deklarative Markup auf dem Produktionsserver anzeigen und bei Bedarf ändern können. Durch die Vorkompilierung mit einer nicht aktualisierbaren Benutzeroberfläche werden Seiten generiert .aspx , die keine Inhalte enthalten und Dateien entfernt .ascx werden .master , wodurch das deklarative Markup ausgeblendet wird und es einem Entwickler untersagt wird, es aus der Produktionsumgebung zu ändern.

Vorkompilieren für die Bereitstellung mit einer aktualisierbaren Benutzeroberfläche

Die beste Möglichkeit, die Vorkompilierung für die Bereitstellung zu verstehen, besteht darin, ein Beispiel in Aktion zu sehen. Lassen Sie uns den WSP "Buchüberprüfungen" für die Bereitstellung mithilfe einer aktualisierbaren Benutzeroberfläche vorkompilieren. Das ASP.NET Kompilierungstool kann über das Build-Menü von Visual Studio oder über die Befehlszeile aufgerufen werden. In diesem Abschnitt wird die Verwendung des Tools in Visual Studio untersucht. Im Abschnitt "Vorkompilieren über die Befehlszeile" wird die Ausführung des Compilertools über die Befehlszeile untersucht.

Öffnen Sie den WSP "Buchüberprüfung" in Visual Studio, wechseln Sie zum Menü Erstellen, und wählen Sie die Menüoption Website veröffentlichen aus. Dadurch wird das Dialogfeld Website veröffentlichen (siehe Abbildung 1) gestartet, in dem Sie den Zielspeicherort angeben können, unabhängig davon, ob die Benutzeroberfläche der vorkompilierten Website aktualisierbar ist oder nicht, und andere Compilertooloptionen. Der Zielspeicherort kann ein Remotewebserver oder FTP-Server sein, aber wählen Sie vorerst einen Ordner auf der Festplatte Ihres Computers aus. Da wir die Website mit einer aktualisierbaren Benutzeroberfläche vorkompilieren möchten, lassen Sie das Kontrollkästchen "Diese vorkompilierte Website kann aktualisierbar sein" aktiviert, und klicken Sie auf OK.

Abbildung 1: Das ASP.NET Kompilierungstool kompiliert Ihre Website vor dem angegebenen Zielspeicherort
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Hinweis

Die Option Website veröffentlichen im Menü Erstellen ist in Visual Web Developer nicht verfügbar. Wenn Sie Visual Web Developer verwenden, müssen Sie die Befehlszeilenversion des Kompilierungstools ASP.NET verwenden, die im Abschnitt "Vorkompilieren über die Befehlszeile" behandelt wird.

Navigieren Sie nach dem Vorkompilieren der Website zu dem Zielspeicherort, den Sie im Dialogfeld Website veröffentlichen eingegeben haben. Nehmen Sie sich einen Moment Zeit, um den Inhalt dieses Ordners mit den Inhalten Ihrer Website zu vergleichen. Abbildung 2 zeigt den Ordner Book Reviews-Website. Beachten Sie, dass es sowohl Dateien als auch .aspx.aspx.cs enthält. Beachten Sie außerdem, dass das Bin Verzeichnis nur eine Datei enthält, Elmah.dlldie wir im vorherigen Tutorial hinzugefügt haben.

Abbildung 2: Das Projektverzeichnis enthält .aspx Und .aspx.cs Dateien; der Bin Ordner enthält Just Elmah.dll
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Abbildung 3 zeigt den Zielspeicherortordner, dessen Inhalt vom Kompilierungstool ASP.NET erstellt wurde. Dieser Ordner enthält keine CodeBehind-Dateien. Darüber hinaus enthält das Verzeichnis dieses Ordners Bin mehrere Assemblys und zwei .compiled Dateien zusätzlich zur Elmah.dll Assembly.

Abbildung 3: Der Zielspeicherortordner enthält die Dateien für die Bereitstellung
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Im Gegensatz zur expliziten Kompilierung in WAPs erstellt die Vorkompilierung für den Bereitstellungsprozess nicht eine Assembly für den gesamten Standort. Stattdessen werden mehrere Seiten in jeder Assembly zusammengefasst. Außerdem werden die Global.asax Datei (sofern vorhanden) in eine eigene Assembly sowie alle Klassen im App_Code Ordner kompiliert. Die Dateien, die das deklarative Markup für ASP.NET Webseiten, Benutzersteuerelemente und Gestaltungsvorlagen (.aspx, .ascxbzw. Dateien .master ) enthalten, werden unverändert in das Zielspeicherortverzeichnis kopiert. Ebenso wird die Web.config Datei direkt kopiert, zusammen mit allen statischen Dateien, z. B. Bildern, CSS-Klassen und PDF-Dateien. Eine formalere Beschreibung der Verarbeitung verschiedener Dateitypen durch das Kompilierungstool finden Sie unter Dateibehandlung während ASP.NET Vorkompilierung.

Hinweis

Sie können das Kompilierungstool anweisen, eine Assembly pro ASP.NET Seite, Benutzersteuerung oder Gestaltungsvorlage zu erstellen, indem Sie im Dialogfeld Website veröffentlichen das Kontrollkästchen "Feste Benennung und Assemblys für einzelne Seiten verwendet" aktivieren. Wenn jede ASP.NET Seite in eine eigene Assembly kompiliert wird, können Sie die Bereitstellung präziser steuern. Wenn Sie beispielsweise eine einzelne ASP.NET Webseite aktualisiert haben und diese Änderung bereitstellen müssen, müssen Sie nur die Datei dieser Seite .aspx und die zugehörige Assembly in der Produktionsumgebung bereitstellen. Weitere Informationen finden Sie unter Vorgehensweise: Generieren von festen Namen mit dem ASP.NET Kompilierungstool .

Das Zielspeicherortverzeichnis enthält auch eine Datei, die nicht Teil des vorkompilierten Webprojekts war, nämlich PrecompiledApp.config. Diese Datei informiert die ASP.NET Runtime darüber, dass die Anwendung vorkompiliert wurde und ob sie mit einer aktualisierbaren oder nicht aktualisierbaren Benutzeroberfläche vorkompiliert wurde.

Nehmen Sie sich schließlich einen Moment Zeit, um eine der .aspx Dateien am Zielspeicherort mit Visual Studio oder Ihrem Text-Editor Ihrer Wahl zu öffnen. Beim Vorkompilieren für die Bereitstellung mit einer aktualisierbaren Benutzeroberfläche enthalten die ASP.NET Seiten im Zielspeicherortverzeichnis genau das gleiche Markup wie die entsprechenden Dateien auf der Website.

Vorkompilierung für die Bereitstellung mit einer nicht aktualisierbaren Benutzeroberfläche

Das ASP.NET Compilertool kann auch verwendet werden, um einen Standort für die Bereitstellung mit einer nicht aktualisierbaren Benutzeroberfläche vorkompilieren. Das Vorkompilieren der Website mit einer nicht aktualisierbaren Benutzeroberfläche funktioniert ähnlich wie das Vorkompilieren mit einer aktualisierbaren Benutzeroberfläche. Der Hauptunterschied besteht darin, dass die ASP.NET Seiten, Benutzersteuerelemente und Gestaltungsvorlagen im Zielverzeichnis das Markup entfernt werden. Wenn Sie eine Website für die Bereitstellung mit einer nicht aktualisierbaren Benutzeroberfläche vorkompilieren möchten, wählen Sie im Menü Erstellen die Option Website veröffentlichen aus, deaktivieren Sie jedoch die Option "Diese vorkompilierte Website kann aktualisierbar sein" (siehe Abbildung 4).

Abbildung 4: Deaktivieren Sie die Option "Diese vorkompilierte Website kann aktualisierbar sein", um mit einer nicht aktualisierbaren Benutzeroberfläche vorkompiliert zu werden.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Abbildung 5 zeigt den Zielspeicherortordner nach dem Vorkompilieren mit einer nicht aktualisierbaren Benutzeroberfläche.

Abbildung 5: Zielspeicherortordner für die Bereitstellung mit einer nicht aktualisierbaren Benutzeroberfläche
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Vergleichen Sie Abbildung 3 mit Abbildung 5. Obwohl die beiden Ordner möglicherweise identisch aussehen, beachten Sie, dass dem nicht aktualisierbaren Benutzeroberflächenordner die Gestaltungsvorlage fehlt. Site.master Abbildung 5 enthält die verschiedenen ASP.NET Seiten, aber wenn Sie den Inhalt dieser Dateien anzeigen, sehen Sie, dass sie ihr deklaratives Markup entfernt und durch den Platzhaltertext ersetzt wurden: "Dies ist eine Markerdatei, die vom Vorkompilierungstool generiert wurde und nicht gelöscht werden sollte!"

Abbildung 5: Das deklarative Markup wurde aus den ASP.NET Seiten entfernt

Die Bin Ordner in Den Abbildungen 3 und 5 unterscheiden sich erheblicher. Zusätzlich zu den Assemblys enthält der Bin Ordner in Abbildung 5 eine .compiled Datei für jede ASP.NET Seite, Benutzersteuerung und Gestaltungsvorlage.

Das Vorkompilieren einer Website mit einer nicht aktualisierbaren Benutzeroberfläche ist in Situationen nützlich, in denen der Inhalt der ASP.NET Seiten nicht von der Person oder dem Unternehmen geändert werden soll, das die Website in der Produktionsumgebung installiert oder verwaltet. Wenn Sie eine ASP.NET Webanwendung erstellen, die Sie an Kunden verkaufen, um sie auf ihren eigenen Webservern zu installieren, sollten Sie sicherstellen, dass sie das Erscheinungsbild Ihrer Website nicht ändern, indem Sie die .aspx von Ihnen gelieferten Seiten direkt bearbeiten. Indem Sie Ihre Website mit einer nicht aktualisierbaren Benutzeroberfläche vorkompilieren, versenden Sie die Platzhalterseiten .aspx im Rahmen der Installation, wodurch Ihre Kunden daran hindern, ihren Inhalt zu überprüfen oder zu ändern.

Vorkompilieren über die Befehlszeile

Im Hintergrund ruft das Visual Studio-Dialogfeld Website veröffentlichen das Kompilierungstool ASP.NET (aspnet_compiler.exe) auf, um die Website vorkompilieren zu können. Alternativ können Sie dieses Tool über die Befehlszeile aufrufen. Wenn Sie Visual Web Developer verwenden, müssen Sie das Compilertool über die Befehlszeile ausführen, da das Buildmenü von Visual Web Developer die Option Website veröffentlichen nicht enthält.

Um das Compilertool über die Befehlszeile zu verwenden, beginnen Sie, indem Sie zur Befehlszeile wechseln und zum Frameworkverzeichnis navigieren. %WINDIR%\Microsoft.NET\Framework\v2.0.50727 Geben Sie als Nächstes die folgende Anweisung in die Befehlszeile ein:

aspnet_compiler -p "physical_path_to_app" -v / -f -u "target_location_folder"

Der obige Befehl startet das ASP.NET-Compilertool (aspnet_compiler.exe) und weist es über den -p Schalter an, die Website, die bei physical_path_to_app verwurzelt ist, vorkompilieren. Dieser Wert ist etwa wie C:\MySites\BookReviews, und sollte durch Anführungszeichen getrennt werden.

Der -v Switch gibt das virtuelle Verzeichnis des Standorts an. Wenn Ihre Website als Standardwebsite in der IIS-Metabasis registriert ist, können Sie den -p Schalter weglassen und einfach das virtuelle Verzeichnis der Anwendung angeben. Wenn Sie den -p Switch verwenden, gibt der Wert, der den -v Switch fortschreitet, den Stamm der Website an und wird verwendet, um Anwendungsstammverweise aufzulösen. Wenn Sie beispielsweise einen Wert von -v /MySite angeben, werden Verweise in der Anwendung als ~/path/file~/MySite/path/fileaufgelöst. Da sich die Website Buchbewertungen im Stammverzeichnis meines Webhostingunternehmens befindet, habe ich den Schalter -v /verwendet.

Der -f Schalter weist das Kompilierungstool an, das Verzeichnis target_location_folder zu überschreiben, sofern es bereits vorhanden ist. Wenn Sie den -f Schalter weglassen und der Zielspeicherortordner bereits vorhanden ist, wird das Kompilierungstool mit der Fehlermeldung beendet: "Error ASPRUNTIME: The target directory is not empty. Löschen Sie es manuell, oder wählen Sie ein anderes Ziel aus."

Falls -u vorhanden, informiert der Switch das Tool, eine aktualisierbare Benutzeroberfläche zu erstellen. Lassen Sie diesen Wechsel aus, um die Website mit einer nicht aktualisierbaren Benutzeroberfläche vorkompilieren.

Schließlich ist der target_location_folder der physische Pfad zum Zielspeicherortverzeichnis. Dieser Wert entspricht etwa C:\MySites\Output\BookReviews, und sollte durch Anführungszeichen getrennt werden.

Bereitstellen der vorkompilierten Website

An diesem Punkt haben wir erfahren, wie Sie das Kompilierungstool ASP.NET verwenden, um eine Website mit den aktualisierbaren und nicht aktualisierbaren Benutzeroberflächesoptionen vorkompilieren. In unseren bisherigen Beispielen wurde die Website jedoch in einen lokalen Ordner und nicht in die Produktionsumgebung vorkompiliert. Die gute Nachricht ist, dass die Bereitstellung der vorkompilierten Website ein Kinderspiel ist und über Visual Studio oder über einen anderen Dateikopiemechanismus erfolgen kann, z. B. über einen eigenständigen FTP-Client.

Das Dialogfeld Website veröffentlichen (zuerst in Abbildung 1 dargestellt) verfügt über eine Zielspeicherortoption, die angibt, wohin die vorkompilierten Websitedateien kopiert werden. Dieser Speicherort kann ein Remotewebserver oder ein FTP-Server sein. Das Eingeben eines Remoteservers in dieses Textfeld wird vorkompiliert und stellt die Website in einem Schritt auf dem angegebenen Server bereit. Alternativ können Sie die Website in einen lokalen Ordner vorkompilieren und dann den Inhalt dieses Ordners manuell per FTP oder einem anderen Ansatz in die Produktionsumgebung kopieren.

Die automatische Bereitstellung der vorkompilierten Website über das Dialogfeld Website veröffentlichen von Visual Studio ist hilfreich für einfache Websites, bei denen es keine Konfigurationsunterschiede zwischen den Entwicklungs- und Produktionsumgebungen gibt. Wie im Tutorial Allgemeine Konfigurationsunterschiede zwischen Entwicklung und Produktion erwähnt, ist es jedoch nicht ungewöhnlich, dass solche Unterschiede vorhanden sind. Beispielsweise verwendet die Book Reviews-Webanwendung eine andere Datenbank in der Produktionsumgebung als in der Entwicklungsumgebung. Wenn Visual Studio die Website auf einem Remoteserver veröffentlicht, kopiert es blind die Konfigurationsdateiinformationen in der Entwicklungsumgebung.

Für Standorte mit Konfigurationsunterschieden zwischen entwicklungs- und Produktionsumgebungen empfiehlt es sich, den Standort in ein lokales Verzeichnis vorkompilieren, die produktionsspezifischen Konfigurationsdateien zu kopieren und dann den Inhalt der vorkompilierten Ausgabe in die Produktion zu kopieren.

Eine Aktualisierung zum Kopieren von Dateien aus der Entwicklungsumgebung in die Produktionsumgebung finden Sie in den Tutorials Bereitstellen Ihrer Website mithilfe eines FTP-Clients und Bereitstellen Ihrer Website mithilfe von Visual Studio .

Zusammenfassung

ASP.NET unterstützt zwei Kompilierungsmodi: automatisch und explizit. Wie in den vorherigen Tutorials erläutert, verwenden WaPs (Web Application Projects) die explizite Kompilierung, während Web Site Projects (WSPs) standardmäßig die automatische Kompilierung verwenden. Es ist jedoch möglich, einen WSP vor der Bereitstellung explizit zu kompilieren, indem Sie das Kompilierungstool ASP.NET verwenden.

Dieses Tutorial konzentrierte sich auf die Vorkompilierung des Kompilierungstools für die Bereitstellungsunterstützung. Beim Vorkompilieren für die Bereitstellung erstellt das Kompilierungstool einen Zielspeicherortordner, kompiliert den Quellcode der angegebenen Webanwendung und kopiert diese kompilierten Assemblys und die Inhaltsdateien in den Zielspeicherortordner. Das Kompilierungstool kann so konfiguriert werden, dass eine aktualisierbare oder nicht aktualisierbare Benutzeroberfläche erstellt wird. Beim Vorkompilieren mit einer nicht aktualisierbaren Benutzeroberfläche wird das deklarative Markup in den Inhaltsdateien entfernt. Kurz gesagt, die Vorkompilierung ermöglicht Es Ihnen, Ihre websiteprojektbasierte Anwendung bereitzustellen, ohne Quellcodedateien zu enthalten und bei Bedarf das deklarative Markup zu entfernen.

Viel Spaß beim Programmieren!

Weitere Informationen

Weitere Informationen zu den in diesem Tutorial erläuterten Themen finden Sie in den folgenden Ressourcen:

• ASP.NET Website-Vorkompilierung
• Codebehind und Kompilierung in ASP.NET 2.0
• Vorkompilierung in ASP.NET
• Vorkompilierte Standortoptionen in ASP.NET

ZurückWeiter