Vorkompilieren Ihrer Website (VB)

von Scott Mitchell

Visual Studio bietet ASP.NET Entwicklern zwei Arten von Projekten: Webanwendungsprojekte (WAPs) und Websiteprojekte (Web Site Projects, WSPs). Einer der wichtigsten Unterschiede zwischen den beiden Projekttypen besteht darin, dass WAPs den Code vor der Bereitstellung explizit kompiliert haben müssen, während der Code in einem WSP automatisch auf dem Webserver kompiliert werden kann. Es ist jedoch möglich, einen WSP vor der Bereitstellung vorab zu kompilieren. In diesem Lernprogramm werden die Vorteile der Vorkompilierung erläutert und gezeigt, wie Sie eine Website aus Visual Studio und über die Befehlszeile vorab kompilieren.

Einführung

Visual Studio bietet ASP.NET Entwicklern zwei verschiedene Projekttypen: Webanwendungsprojekte (WAP) und Websiteprojekte (WSP). Einer der wichtigsten Unterschiede zwischen diesen Projekttypen besteht darin, dass WAPs explizit kompiliert werden müssen, 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.ascx und .master Dateien) im Projekt zusammen mit der Assembly im Bin Ordner; die Code-Behind-Klassendateien selbst müssen nicht bereitgestellt werden. Andererseits stellen Sie WSPs bereit, indem Sie sowohl die Markupseiten als auch die entsprechenden Code-Behind-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 nur die dateien, die geändert wurden, müssen bereitgestellt werden, während für die explizite Kompilierung die Bereitstellung der geänderten Markupseiten und der gerade kompilierten Assembly erforderlich ist. Die automatische Bereitstellung hat jedoch zwei mögliche Nachteile:

• Da die Seiten beim ersten Besuch automatisch kompiliert werden müssen, kann es eine kurze, aber spürbare Verzögerung geben, wenn eine ASP.NET Seite zum ersten Mal nach der Bereitstellung angefordert wird.
• Für die automatische Kompilierung muss sowohl das deklarative Markup als auch der Quellcode auf dem Webserver vorhanden sein. Dies kann eine unattraktive Option sein, wenn Sie beabsichtigen, die Webanwendung an Kunden zu verkaufen, die sie auf ihren Webservern installieren werden.

Wenn eines der beiden oben genannten Ausschlusskriterien zutrifft, können Sie entweder zum WAP-Modell wechseln oder den WSP vor der Bereitstellung kompilieren. In diesem Lernprogramm werden die Vorkompilierungsoptionen untersucht, die für eine gehostete Website am besten geeignet sind, und führt Sie durch den Vorkompilierungsprozess und die Bereitstellung einer vorkompilierten Website.

Eine Übersicht über ASP.NET Codegenerierung und Kompilierung

Bevor wir uns die verfügbaren Vorkompilierungsoptionen ansehen, befassen wir uns zunächst mit der Codegenerierung und Kompilierung, die auftritt, wenn eine ASP.NET Seite zum ersten Mal angefordert wird, seit sie erstellt oder zuletzt aktualisiert wurde. Wie Sie wissen, bestehen ASP.NET Seiten aus zwei Teilen: deklarativem Markup in der .aspx Datei und einem Quellcodeteil, in der Regel in einer separaten CodeBehind-Klassendatei (.aspx.vb). Die Schritte, die von der Laufzeit ausgeführt werden, wenn eine ASP.NET Seite angefordert wird, hängt vom Kompilierungsmodell der Anwendung ab.

Bei WAPs muss der Quellcode der Seiten explizit in eine einzelne Assembly kompiliert werden, bevor sie bereitgestellt wird. Während der Bereitstellung werden diese Assembly-Version und die verschiedenen Markup-Seiten in die Produktionsumgebung kopiert. Wenn eine Anforderung für eine ASP.NET Seite an den Webserver gelangt, erstellt die Laufzeit eine Instanz der CodeBehind-Klasse der Seite und ruft die ProcessRequest Methode auf, die den Seitenlebenszyklus startet und letztendlich den Inhalt der Seite generiert, der an den Anforderer zurückgegeben wird. Die Laufzeit 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. Bei der Bereitstellung muss stattdessen 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 ihrer Erstellung oder letzten Aktualisierung auf dem Webserver eingeht, muss die Laufzeit die Code-behind-Klasse zuerst 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 ist, muss sie nicht auf nachfolgenden Anforderungen auf derselben Seite neu kompiliert werden.

Mit expliziter Kompilierung müssen Sie den Quellcode der Website vor der Bereitstellung kompilieren, wodurch die Laufzeit von der Ausführung dieses Schritts entlastet wird. Bei der automatischen Kompilierung übernimmt die Laufzeitumgebung die Kompilierung des Quellcodes der Seiten, wobei es beim ersten Aufruf der Seite einen geringen Initialisierungsaufwand gibt, falls die Seite seit ihrer Erstellung oder ihrer letzten Aktualisierung noch nicht besucht wurde.

Aber was ist mit dem deklarativen Teil ASP.NET Seiten (die .aspx Datei)? Es ist offensichtlich, dass es eine Beziehung zwischen den .aspx Dateien und dem Code in ihren CodeBehind-Klassen gibt, da auf die im deklarativen Markup definierten Websteuerelemente im Code zugegriffen werden kann. Es ist auch offensichtlich, dass der Inhalt in den .aspx Dateien stark das gerenderte Markup beeinflusst, das von der Seite generiert wird. Wie funktioniert also die Laufzeitumgebung mit der Text-, HTML- und Webcontrol-Syntax, die in der .aspx Datei definiert ist, um den gewünschten Inhalt der Seite zu rendern?

Ich möchte mich nicht zu sehr von den Implementierungsdetails ablenken lassen, die zwischen WAPs und WSPs variieren, aber kurz gesagt generiert das Laufzeitsystem automatisch eine Klassendatei, die die verschiedenen Web-Controls als geschützte Mitglieder und Methoden enthält. Diese generierte Datei wird als Teilklasse für die entsprechende CodeBehind-Klasse implementiert. (Teilklassen ermöglichen, dass der Inhalt einer einzelnen Klasse über mehrere Dateien verteilt wird.) 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 Laufzeit erstellt wurde. Diese automatisch generierte Klasse wird im %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files Ordner gespeichert.

Wichtig ist hier, dass eine ASP.NET-Seite von der Laufzeit nur dann gerendert werden kann, wenn sowohl ihr deklarativer Teil als auch ihr Quellcode in eine Assembly kompiliert wurden. Bei WAPs wird der Quellcode vor der Bereitstellung explizit in eine Assembly kompiliert, das deklarative Markup muss jedoch weiterhin in Code konvertiert und von der Laufzeit 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 kompilieren.

Vorkompilierungsoptionen

Das .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 .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 über die Option "Website veröffentlichen" in Visual Studio gestartet werden.

Das Kompilierungstool bietet zwei allgemeine Kompilierungsformen: 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 Sie 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, wobei die kompilierte Version im %WINDIR%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files Ordner gespeichert wird, genau wie wenn die Seiten jeweils zum ersten Mal über einen Browser besucht wurden. Vor-Ort-Vorkompilierung kann die erste Anforderung an neu bereitgestellte ASP.NET-Seiten auf Ihrer Website beschleunigen, da dieser Schritt zur Laufzeit nicht mehr erforderlich ist. Die direkte Vorkompilierung ist jedoch für die Mehrzahl der 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 der Website in den Ordner Temporary ASP.NET Files zu kompilieren, erfolgt die Vorkompilierung zur Bereitstellung in einem 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 Lernprogramm untersuchen: Vorkompilierung mit einer aktualisierbaren Benutzeroberfläche und Vorkompilierung mit einer nicht aktualisierbaren Benutzeroberfläche. Vorkompilierung mit einer aktualisierbaren Benutzeroberfläche lässt das deklarative Markup in den .aspx, .ascx, und .master Dateien stehen, wodurch ein Entwickler das deklarative Markup auf dem Produktionsserver ansehen und bei Bedarf ändern kann. Vorkompilierung mit einer nicht aktualisierbaren Benutzeroberfläche generiert .aspx Seiten, die keinen Inhalt haben, und entfernt .ascx und .master Dateien, wodurch das deklarative Markup ausgeblendet wird und verhindert wird, dass ein Entwickler es in der Produktionsumgebung ändert.

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. Wir sollten den "Book Reviews WSP" für die Bereitstellung unter Verwendung einer aktualisierbaren Benutzeroberfläche vorkompilieren. Das ASP.NET Kompilierungstool kann über das Menü "Erstellen" oder über die Befehlszeile von Visual Studio aufgerufen werden. In diesem Abschnitt wird die Verwendung des Tools in Visual Studio untersucht; Der Abschnitt "Precompiling from the Command Line" befasst sich mit dem Ausführen des Compilertools über die Befehlszeile.

Öffnen Sie den WSP "Buchrezension" in Visual Studio, wechseln Sie zum Menü "Build" und wählen Sie die Menüoption "Publish Web Site" aus. Dadurch wird das Dialogfeld "Website veröffentlichen" gestartet (siehe Abbildung 1), in dem Sie den Zielspeicherort angeben können, ob die Benutzeroberfläche der vorkompilierten Website aktualisierbar ist oder nicht, sowie andere Compiler-Tool-Optionen. Der Zielspeicherort kann ein Remotewebserver oder FTP-Server sein, aber wählen Sie jetzt 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", und klicken Sie auf "OK".

Abbildung 1: Das ASP.NET-Kompilierungstool wird Ihre Website an den angegebenen Zielspeicherort vorkompilieren.
(Klicken Sie hier, um das Bild in voller Größe anzuzeigen)

Navigieren Sie nach dem Vorkompilieren der Website zum Zielspeicherort, den Sie im Dialogfeld "Webseite 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 sie sowohl .aspx als auch .aspx.cs Dateien enthält. Beachten Sie außerdem, dass das Bin Verzeichnis nur eine Datei enthält, Elmah.dlldie wir im vorherigen Lernprogramm hinzugefügt haben.

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

Abbildung 3 zeigt den Zielspeicherortordner, dessen Inhalt vom ASP.NET Kompilierungstool erstellt wurde. Dieser Ordner enthält keine CodeBehind-Dateien. Darüber hinaus enthält das Verzeichnis dieses Ordners Bin mehrere Assemblies 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 keine Assembly für den gesamten Standort. Mehrere Seiten werden stattdessen in jeder Assembly zusammengefasst. Außerdem wird 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 enthalten (.aspx, .ascx und .master Dateien), werden unverändert in das Verzeichnis des Zielspeicherorts kopiert. Ebenso wird die Web.config Datei direkt neben statischen Dateien kopiert, z. B. Bilder, CSS-Klassen und PDF-Dateien. Eine formellere Beschreibung, wie das Kompilierungstool verschiedene Dateitypen verarbeitet, 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-Laufzeitumgebung darüber, dass die Anwendung vorkompiliert wurde und ob sie mit einer aktualisierbaren oder nicht aktualisierbaren Benutzeroberfläche vorkompiliert wurde.

Nehmen Sie sich zum Schluss einen Moment Zeit, um eine der .aspx Dateien am Zielspeicherort mit Visual Studio oder ihrem Texteditor zu öffnen. Bei der Vorkompilierung für die Bereitstellung mit einer aktualisierbaren Benutzeroberfläche enthalten die ASP.NET Seiten im Zielspeicherortverzeichnis das genaue 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 eine Website 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 auf ihr Markup reduziert 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 aktualisierbar machen", um mit einer nicht aktualisierbaren Benutzeroberfläche zu vorkompilieren.
(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: Der 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. Während die beiden Ordner möglicherweise identisch aussehen, beachten Sie, dass der nicht aktualisierbare Benutzeroberflächenordner die Gestaltungsvorlage Site.masternicht enthält. Und während Abbildung 5 die verschiedenen ASP.NET Seiten enthält, sehen Sie, dass die Inhalte dieser Dateien entfernt und durch den Platzhaltertext ersetzt wurden: "Dies ist eine Markerdatei, die vom Vorkompilierungstool generiert wird 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, jedes Benutzersteuerelement und jede Masterseite.

Das Vorabkompilieren einer Website mit einer nicht aktualisierbaren Benutzeroberfläche ist in Situationen hilfreich, in denen sie nicht möchten, dass die Inhalte der ASP.NET Seiten von der Person oder dem Unternehmen geändert werden, die 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 Aussehen und Verhalten 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, senden Sie die Platzhalterseiten .aspx als Teil der Installation, wodurch Ihre Kunden daran hindern, ihre Inhalte zu untersuchen oder zu ändern.

Vorkompilieren über die Befehlszeile

Im Hintergrund ruft das Dialogfeld "Website veröffentlichen" von Visual Studio das ASP.NET Kompilierungstool (aspnet_compiler.exe) auf, um die Website vorab zu kompilieren. 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 Menü "Erstellen" von Visual Web Developer nicht die Option "Website veröffentlichen" enthält.

Um das Compilertool über die Befehlszeile zu verwenden, öffnen Sie zunächst die Befehlszeilenoberfläche und navigieren Sie zum Framework-Verzeichnis, %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 oben genannte Befehl startet das ASP.NET Compilertool (aspnet_compiler.exe) und weist es über den -p Schalter an, die Website, die mit physical_path_to_app verwurzelt ist, vorkompilieren. Dieser Wert ist ungefähr wie C:\MySites\BookReviews, und sollte durch Anführungszeichen getrennt werden.

Die -v Option gibt das virtuelle Verzeichnis der Website an. Wenn Ihre Website als Standardwebsite in der IIS-Metabasis registriert ist, können Sie die -p Option weglassen und einfach das virtuelle Verzeichnis der Anwendung angeben. Wenn Sie den -p Schalter verwenden, zeigt der Wert, der dem -v Schalter folgt, das Wurzelverzeichnis der Website an und dient dazu, Verweise auf den Anwendungsstamm aufzulösen. Wenn Sie beispielsweise einen Wert von -v /MySite angeben, werden Verweise in der Anwendung auf ~/path/file als ~/MySite/path/file aufgelöst. Da sich die Website "Book Reviews" im Stammverzeichnis meines Webhosting-Unternehmens befindet, habe ich die Option -v /verwendet.

Wenn vorhanden, weist der -f Switch das Kompilierungstool an, das target_location_folder Verzeichnis zu überschreiben, falls er bereits vorhanden ist. Wenn Sie den -f Schalter weglassen und das Zielverzeichnis bereits vorhanden ist, wird das Kompilierungstool mit dem Fehler "Fehler ASPRUNTIME: Das Zielverzeichnis ist nicht leer." beendet. Löschen Sie es manuell, oder wählen Sie ein anderes Ziel aus."

Wenn der -u Schalter vorhanden ist, weist er das Tool an, eine aktualisierbare Benutzeroberfläche zu erstellen. Lassen Sie diesen Schalter weg, um die Website mit einer nicht aktualisierbaren Benutzeroberfläche vorzukompilieren.

Schließlich ist der target_location_folder der physische Pfad zum Zielspeicherortverzeichnis; Dieser Wert sieht ungefähr so aus C:\MySites\Output\BookReviewsund sollte durch Anführungszeichen getrennt werden.

Bereitstellen der vorkompilierten Website

An diesem Punkt haben wir gesehen, wie Sie das ASP.NET Kompilierungstool verwenden, um eine Website mit den aktualisierbaren und nicht aktualisierbaren Benutzeroberflächenoptionen vorkompilieren zu können. Unsere Beispiele haben die Website bisher jedoch in einen lokalen Ordner und nicht auf 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 durchgeführt werden kann, z. B. von einem eigenständigen FTP-Client.

Das Dialogfeld "Website veröffentlichen" (zuerst in Abbildung 1 dargestellt) verfügt über eine Zielspeicherortoption, die angibt, in welchen Speicherort die vorkompilierten Websitedateien kopiert werden. Dieser Speicherort kann ein Remotewebserver oder FTP-Server sein. Wenn Sie einen Remoteserver in dieses Textfeld eingeben, wird die Website in einem Schritt auf dem angegebenen Server vorkompiliert und bereitgestellt. Alternativ können Sie die Website in einen lokalen Ordner vorab kompilieren und dann den Inhalt dieses Ordners über FTP oder einen anderen Ansatz manuell in die Produktionsumgebung kopieren.

Die automatische Bereitstellung der vorkompilierten Website über das Dialogfeld "Website veröffentlichen" von Visual Studio ist für einfache Websites hilfreich, bei denen es keine Konfigurationsunterschiede zwischen entwicklungs- und Produktionsumgebungen gibt. Wie im Lernprogramm "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 sie blind die Konfigurationsdateiinformationen in der Entwicklungsumgebung.

Für Websites mit Konfigurationsunterschieden zwischen entwicklungs- und Produktionsumgebungen kann es am besten sein, die Website in ein lokales Verzeichnis vorkompilieren, die produktionsspezifischen Konfigurationsdateien zu kopieren und dann den Inhalt der vorkompilierten Ausgabe in die Produktion zu kopieren.

Eine Auffrischung zum Kopieren von Dateien aus der Entwicklungsumgebung in die Produktionsumgebung finden Sie unter " Deploying Your Website Using an FTP Client and Deploying Your Website Using Visual Studio tutorials".

Zusammenfassung

ASP.NET unterstützt zwei Kompilierungsmodi: automatisch und explizit. Wie in früheren Lernprogrammen erläutert, verwenden Webanwendungsprojekte (WAPs) explizite Kompilierung, während Websiteprojekte (WSPs) standardmäßig die automatische Kompilierung verwenden. Es ist jedoch möglich, einen WSP vor der Bereitstellung explizit mithilfe des ASP.NET Kompilierungstools zu kompilieren.

Dieses Lernprogramm konzentriert sich auf die Precompilation 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ächenoption wird das deklarative Markup in den Inhaltsdateien entfernt. Kurz gesagt, die Vorkompilierung ermöglicht es Ihnen, Ihre Project-basierte Websiteanwendung bereitzustellen, ohne Quellcodedateien und bei Bedarf das deklarative Markup zu entfernen.

Glückliche Programmierung!

Weiterführende Lektüre

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

• ASP.NET Websitevorkompilierung
• Codebehind und Kompilierung in ASP.NET 2.0
• Vorkompilierung in ASP.NET
• Vorkompilierte Websiteoptionen in ASP.NET