(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen.
Übersetzung
Original

Dynamische ASP.NET-Kompilierung

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.

Die dynamische Kompilierung von ASP.NET ermöglicht Ihnen die Änderung des Quellcodes, ohne eine explizite Kompilierung des Codes vor der Bereitstellung der Webanwendung durchführen zu müssen. 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.

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 Dateitypen in ASP.NET-Webprojekten. 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.

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 je nach Änderung der Ressourcen eine einzelne Seite oder eine gesamte Website neu kompiliert werden kann.)

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 Ordnerstruktur für ASP.NET-Webprojekte und im Abschnitt "Kompilierungslebenszyklus" von Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0.

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 How to: Run the Worker Process Under a User Account.

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.

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-Webprojekten und Exemplarische Vorgehensweise: Verwenden mehrerer Programmiersprachen in einem Websiteprojekt.

Wenn an einer Datei der obersten Ebene in einer Website eine Änderung vorgenommen wird, wird standardmäßig die gesamte Site neu kompiliert. Zu den Dateien der obersten Ebene gehören die Datei "global.asax" und alle Dateien in den Ordnern "Bin" und "App_Code". Wenn sich eine dieser Dateien ändert, ist es am sichersten, alles neu zu kompilieren, da andere Dateien der Site, z. B. ASPX- und ASCX-Dateien, möglicherweise auf die Objekte verweisen, die mit Code aus den Dateien der obersten Ebene erstellt wurden.

Eine Neukompilierung funktioniert bei den meisten Anwendungen zwar problemlos, eine sehr große Anwendung könnte allerdings für längere Zeit nicht verfügbar sein, selbst wenn nur geringfügige Änderungen daran vorgenommen wurden. Wenn die Anwendung groß genug ist, könnte sie für fünf bis zehn Minuten oder länger nicht verfügbar sein, nachdem eine Änderung vorgenommen wurde.

Wenn Sie in der Lage sein möchten, Dateien der obersten Ebene zu ändern, ohne dass die gesamte Site neu kompiliert wird, können Sie das "optimizeCompilations"-Attribut des Kompilierungselements in der Datei "Web.config" auf "true" festlegen. Wenn "optimizeCompilations" beim Ändern einer Datei der obersten Ebene den Wert "true" aufweist, werden nur die betroffenen Dateien neu kompiliert. Dies spart Zeit, kann jedoch je nach Art der Änderung an einer Datei der obersten Ebene zu Laufzeitfehlern führen.

Die folgenden Arten von Änderungen sind im Allgemeinen sicher:

  • Das Ändern einer Methodenimplementierung. Da die Signatur nicht geändert wird, können anhand der alten Version kompilierte Seiten die Methode aufrufen, ohne eine Ausnahme auszulösen.

  • Das Hinzufügen von neuen Methoden oder Eigenschaften. Da diese zuvor nicht vorhanden waren, verweisen keine bereits kompilierten Seiten auf sie, und keine Ausnahmen werden ausgelöst.

  • Das Hinzufügen eines CLR-Attributs zu einem vorhandenen Member. Dies ist ein typisches Dynamic Data-Szenario, in dem Sie Eigenschaften Attribute wie "DisplayName" hinzufügen. Da CLR-Attribute zur Laufzeit durch Reflektion ermittelt werden, müssen vorhandene Seiten nicht neu kompiliert werden.

Die folgenden Arten von Änderungen verursachen möglicherweise Laufzeitausnahmen:

  • Das Umbenennen oder Löschen von Methoden oder Eigenschaften. Wenn auf den betroffenen Member von einer bereits kompilierten Seite verwiesen wird, wird eine Ausnahme ausgelöst.

  • Das Ändern der Signatur einer Methode oder des Typs einer Eigenschaft. Wenn auf den betroffenen Member von einer bereits kompilierten Seite verwiesen wird, wird eine Ausnahme ausgelöst. Einige Signaturänderungen würden keine Kompilierungs- oder Laufzeitfehler verursachen, wenn die gesamte Site neu kompiliert wird. Der Code Response.Write(ClassA.MethodA() auf einer ASPX-Seite wird beispielsweise kompiliert und ordnungsgemäß ausgeführt, unabhängig davon, ob MethodA "int" oder "short" zurückgibt. Aber wenn die ASPX-Seite bereits kompiliert ist und Sie den Rückgabetyp von MethodA von "int" in "short" ändern, ohne neu zu kompilieren, wird eine Laufzeitausnahme ausgelöst, da der kompilierte Code die "int"-Signatur erwartet.

Wenn Sie das "optimizeCompilations"-Attribut verwenden, um die dynamische Kompilierungszeit zu minimieren, sollten Sie jede Änderung, die Sie an Dateien der obersten Ebene auf der Site vornehmen, sorgfältig überprüfen. Ist eine bestimmte Änderung nicht sicher, entfernen Sie vorübergehend das "optimizeCompilations"-Attribut oder legen es auf "false" fest.

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.

Community-Beiträge

HINZUFÜGEN
Anzeigen:
© 2014 Microsoft