Dynamische ASP.NET-Kompilierung

Článek
10/22/2014

Aktualisiert: November 2007

Damit Ihre Webanwendung auf Anforderungen reagieren kann, muss der Code der Webanwendung zuerst von ASP.NET analysiert und in eine oder mehrere Assemblys kompiliert werden. Wenn der Code kompiliert wurde, wird er in eine sprach- und prozessorunabhängige Darstellung übersetzt, die als Microsoft Intermediate Language (MSIL) bezeichnet wird. Zur Laufzeit wird MSIL im Kontext von .NET Framework ausgeführt, wobei MSIL in spezifische Anweisungen für den Prozessor des Computers übersetzt wird, auf dem die Anwendung ausgeführt wird.

Kompilieren bei der ersten Anforderung

Standardmäßig werden ASP.NET-Webseiten und Codedateien bei der ersten Anforderung einer Ressource, z. B. einer ASP.NET-Seite (ASPX-Datei) über eine Website dynamisch kompiliert. Nach dem ersten Kompilieren der Seiten und Codedateien werden die kompilierten Ressourcen zwischengespeichert, sodass die Seite für nachfolgende Anforderungen sehr schnell zur Verfügung steht.

ASP.NET unterstützt die dynamische Kompilierung von ASP.NET-Seiten (ASPX-Dateien), ASP.NET-Webdiensten (ASMX-Dateien), ASP.NET-HTTP-Handlern (ASHX-Dateien) und ASP.NET-Anwendungsdateien (Global.asax) sowie anderer Dateien, z. B. Quellcode- und Klassendateien. Weitere Informationen zu ASP.NET-Dateitypen finden Sie unter Website-Dateitypen. Weitere Informationen über den ASP.NET-Kompilierungsprozess finden Sie im Abschnitt "Kompilierungslebenszyklus" von Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0.

Neukompilieren bei Änderung

Bei jeder Änderung einer dynamisch kompilierten Datei wird die zwischengespeicherte kompilierte Assembly automatisch ungültig, und es wird eine Neukompilierung aller betroffenen Ressourcen ausgelöst. Bei der nächsten Anforderung des Codes erkennt ASP.NET, dass sich der Code geändert hat, und die entsprechenden Ressourcen der Webanwendung werden neu kompiliert. Dank dieses Systems können Sie schnell Anwendungen mit minimalem Aufwand für die Kompilierungsverarbeitung entwickeln. (Beachten Sie, dass abhängig von der Änderung der Ressourcen eine einzelne Seite oder eine gesamte Website neu kompiliert werden kann.)

Kompilierungsabhängigkeiten

Bei der ersten Anforderung an eine Anwendung werden die Dateien von ASP.NET in einer bestimmten Reihenfolge kompiliert. Die ersten zu kompilierenden Elemente werden als Elemente der obersten Ebene bezeichnet. Nach der ersten Anforderung werden die Elemente der obersten Ebene nur neu kompiliert, wenn sich eine Abhängigkeit geändert hat.

Zu den Elementen der obersten Ebene gehören die Ordner App_GlobalResources, App_WebResources, Profileigenschaften, der Ordner App_Code und die Datei Global.asax. Nachdem die Elemente der obersten Ebene kompiliert wurden, erfolgt die Kompilierung zusätzlicher Elemente. Dazu gehören der Ordner App_LocalResources, einzelne ASP.NET-Seiten (ASPX-Dateien), ASP.NET-Benutzersteuerelemente (ASCX-Dateien), ASP.NET-HTTP-Handler (ASHX-Dateien) und ASP.NET-HTTP-Module (ASMX-Dateien) sowie Designs, Masterseiten und andere Quellcodedateien.

Weitere Informationen finden Sie in ASP.NET-Websitelayout und im Abschnitt "Kompilierungslebenszyklus" von Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0.

Kompilierungsausgabe

Beim Kompilieren des Codes werden die erstellten Assemblys in einem Ordner auf dem Server zwischengespeichert. Dieser Ordner erfordert entsprechende Berechtigungen, damit der Code korrekt kompiliert und ausgeführt werden kann. Sie können sowohl den Speicherort des Kompilierungsordners als auch die Berechtigungen konfigurieren, mit denen der Code kompiliert und ausgeführt wird.

Speicherort des Kompilierungsordners

Beim Kompilieren einer Webanwendung wird der kompilierte Code standardmäßig im temporären ASP.NET-Dateiordner gespeichert. Dieser Ordner ist ein Unterverzeichnis des Verzeichnisses, in dem das .NET-Framework installiert ist. Gewöhnlich wird der folgende Speicherort verwendet:

%SystemRoot%\Microsoft.NET\Framework\versionNumber\Temporary ASP.NET Files

Für den Kompilierungsordner erforderliche Berechtigungen

Beim .NET-Installationsvorgang werden die temporären ASP.NET-Dateiordner erstellt und Zugriffsberechtigungen für das lokale ASP.NET-Benutzerkonto eingerichtet, das die Berechtigungen mit hoher Vertrauenswürdigkeit besitzt, die für den Zugriff auf den kompilierten Code erforderlich sind. Wenn Sie die Konfiguration oder die Kontoeinstellungen ändern, müssen Sie sicherstellen, dass das verwendete Konto hoch vertrauenswürdige Berechtigungen für den temporären ASP.NET-Dateiordner besitzt. Weitere Informationen finden Sie unter Gewusst wie: Ausführen des Workerprozesses unter einem Benutzerkonto.

Konfigurierbarkeit des Kompilierungsordners

ASP.NET erstellt für jede Anwendung einen separaten Unterordner im temporären ASP.NET-Dateiordner. Sie können das Stammverzeichnis über das tempDirectory-Attribut im Kompilierungsabschnitt der Konfigurationsdatei ändern. Dieses optionale Attribut ermöglicht Ihnen, ein Verzeichnis für die temporäre Dateispeicherung während der Kompilierung anzugeben. Der Standardwert ist eine leere Zeichenfolge (""). Bei einer leeren Zeichenfolge und wenn der aktuelle Prozess die erforderlichen Zugriffsberechtigungen besitzt, werden die Dateien im folgenden Verzeichnis gespeichert:

%FrameworkInstallLocation%\Temporary ASP.NET Files

Weitere Informationen finden Sie unter compilation-Element (ASP.NET-Einstellungsschema) und in der TempDirectory-Eigenschaft des CompilationSection.

Unterstützung mehrerer Sprachen

ASP.NET 2.0 unterstützt mehrere Programmiersprachen in der gleichen Webanwendung. Im Verzeichnis App_Code können Sie einen Unterordner für jede Sprache anlegen, z. B. für C# und Visual Basic. ASP.NET erstellt eine separate Assembly für jeden Unterordner. Weitere Informationen finden Sie unter Ordner für freigegebenen Code in ASP.NET-Websites und Exemplarische Vorgehensweise: Entwickeln von Websites unter Verwendung mehrerer Programmiersprachen.

Vor- und Nachteile der dynamischen Kompilierung

Die dynamische Kompilierung von ASP.NET ermöglicht Ihnen die Änderung des Quellcodes, ohne explizite Kompilierung des Codes vor der Bereitstellung der Website. Wenn Sie eine Quelldatei ändern, wird die Datei von ASP.NET automatisch neu kompiliert, und alle verknüpften Ressourcen werden aktualisiert. Damit die Änderungen wirksam werden, muss der IIS-Server nicht neu gestartet werden. Ein Neustart des IIS-Servers ist nur dann erforderlich, wenn der <processModel>-Abschnitt geändert wurde. Darüber hinaus können Sie das ASP.NET-Buildsystem erweitern, indem Sie benutzerdefinierte Buildanbieter für neue Dateitypen erstellen, die während der Kompilierung aufgerufen werden. Die dynamische Kompilierung des ASP.NET-Buildsystems ist zudem abwärtskompatibel mit älteren ASP.NET-Anwendungsstrukturen und -typen.

Bestimmte Funktionen bietet die dynamische Kompilierung nicht. Durch die dynamische Kompilierung kann es für Benutzer anfänglich zu längeren Reaktionszeiten kommen, da die Seiten und Codedateien bei der ersten Anforderung kompiliert werden müssen. Dies kann besonders bei großen Websites ein Problem sein, die häufig aktualisiert werden. Die dynamische Kompilierung bietet keine Möglichkeit, Kompilierungsfehler zu erkennen, bevor Benutzer auf eine Website zugreifen. Außerdem lässt sich mit der dynamischen Kompilierung keine kompilierte Version der Website erstellen, die ohne den Quellcode auf einem Produktionsserver bereitgestellt werden kann. Wenn eines dieser Probleme Ihre Webanwendungen betrifft, können Sie die Website vorkompilieren. Ausführliche Informationen hierzu finden Sie unter Übersicht über die ASP.NET-Vorkompilierung.

Siehe auch

Sdílet prostřednictvím