Vorkompilieren Ihrer Website (VB)

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 der Code für WAPs 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 Hauptunterschiede 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 umfasst das Kopieren des Markupinhalts (der .aspx.ascxDateien , und .master ) 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.

Die Option für die automatische Kompilierung 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 zu einer kurzen, aber spürbaren Verzögerung kommen, wenn eine ASP.NET Seite zum ersten Mal nach der Bereitstellung 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 planen, die Webanwendung an Kunden zu verkaufen, die sie auf ihren Webservern installieren.

Wenn einer der beiden oben genannten Mängel deal breakers ist, 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 der Vorkompilierungsprozess und die Bereitstellung einer vorkompilierten Website werden erläutert.

Übersicht über ASP.NET Codegenerierung und -kompilierung

Bevor wir uns die verfügbaren Vorkompilierungsoptionen ansehen, sprechen wir zunächst über die Codegenerierung und -kompilierung, 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: deklarativem Markup in der .aspx Datei und einem Quellcodeteil, normalerweise in einer separaten CodeBehind-Klassendatei (.aspx.vb). 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 an den Webserver für eine ASP.NET Seite eingeht, erstellt die Laufzeit eine instance der CodeBehind-Klasse der Seite und ruft deren 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 CodeBehind-Klasse der ASP.NET Seite arbeiten, da die CodeBehind-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 umfasst die Bereitstellung das Kopieren des deklarativen und des Quellcodeinhalts in die Produktionsumgebung. Wenn zum ersten Mal seit der Erstellung oder letzten Aktualisierung der Seite eine Anforderung für eine ASP.NET-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 <pages> -Element in Web.configangepasst werden kann. Da die Assembly auf dem Datenträger gespeichert wird, muss sie bei nachfolgenden Anforderungen an dieselbe Seite nicht erneut kompiliert werden.

Kurz gesagt, bei der expliziten Kompilierung müssen Sie den Quellcode der Website vor der Bereitstellung kompilieren, sodass die Runtime diesen Schritt nicht 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 bei den Implementierungsdetails auf niedriger Ebene, die zwischen WAPs und WSPs variieren, nicht zu querverfolgt werden, aber kurz gesagt generiert die Laufzeit automatisch eine Klassendatei, die die verschiedenen Websteuerelemente als geschützte Member und Methoden enthält. Diese generierte Datei wird als partielle Klasse für die entsprechende CodeBehind-Klasse implementiert. (Partielle Klassen ermöglichen es, den Inhalt einer einzelnen Klasse auf mehrere Dateien zu verteilen.) Daher wird die CodeBehind-Klasse an zwei Stellen definiert: in der .aspx.vb 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 auch das deklarative Markup 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 im Menü 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, genau wie wenn die Seiten jeweils zum ersten Mal von einem Browser aus 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 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.

Anstatt die Seiten auf der Website in den Ordner zu kompilieren, kompiliert die Vorkompilierung für die Temporary ASP.NET Files 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 bleibt das deklarative Markup in den .aspxDateien , .ascxund .master erhalten Entwickler die Möglichkeit, das deklarative Markup auf dem Produktionsserver anzuzeigen und bei Bedarf zu ändern. Bei der Vorkompilierung mit einer nicht aktualisierbaren Benutzeroberfläche werden Seiten generiert.aspx, die keine Inhalte enthalten, und .master Dateien werden entfernt.ascx. Dadurch wird das deklarative Markup ausgeblendet und ein Entwickler daran gehindert, es aus der Produktionsumgebung zu ändern.

Vorkompilierung 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 Menü Build 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 "Buchprü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)

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 .aspx.cs als auch .aspx 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 Dateien und .aspx.cs , 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 zusätzlich zur Elmah.dll Assembly mehrere Assemblys und zwei .compiled Dateien.

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 master Seiten (.aspxbzw. Dateien.master) enthalten, .ascxwerden 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.

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 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 master Seiten im Zielverzeichnis vom Markup entfernt werden. Um eine Website für die Bereitstellung mit einer nicht aktualisierbaren Benutzeroberfläche vorkompilieren zu können, 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 master Seite 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 master Seite.

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 gerootet 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 für instance einen Wert von -v /MySite angeben, werden Verweise in der Anwendung als ~/path/file aufgelöst~/MySite/path/file. 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 zu können. 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. Wenn Sie einen Remoteserver in dieses Textfeld eingeben, wird die Website in einem Schritt vorkompiliert und auf dem angegebenen Server bereitgestellt. 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