Übersicht über die ASP.NET-Vorkompilierung

Aktualisiert: November 2007

ASP.NET kann eine Website vorkompilieren, bevor sie den Benutzern zugänglich gemacht wird. Dies bietet viele Vorteile, z. B. schnellere Antwortzeit, Fehlerüberprüfung, Quellcodeschutz und effiziente Bereitstellung.

Sie können ein Projekt auch kompilieren, indem Sie das Webanwendungsprojektmodell verwenden. Sämtliche Codedateien (eigenständige Dateien, Code-Behind-Dateien und Klassendateien) im Projekt werden in eine einzelne Assembly kompiliert und im Ordner Bin gespeichert. Da bei der Kompilierung eine einzelne Assembly erstellt wird, können Sie Attribute wie Name und Version angeben. Sie können den Speicherort der Ausgabe-Assembly auch angeben, wenn Sie einen anderen Speicherort als das Verzeichnis Bin verwenden möchten. Weitere Informationen finden Sie unter Kompilieren von Webanwendungsprojekten.

Dieses Thema enthält folgende Abschnitte:

• Szenarien

• Vorkompilierungsfeatures

• Hintergrund

• Codebeispiele

Features

Das Vorkompilieren einer ASP.NET-Website bietet die folgenden Vorteile:

• Die Antwortzeiten für Benutzer sind schneller, da Seiten und Codedateien nicht erst bei der ersten Anforderung kompiliert werden. Dies empfiehlt sich besonders für umfangreiche Sites, die häufig aktualisiert werden.

• Kompilierungsprobleme werden erkannt, bevor die Site dem Benutzer angezeigt wird.

• Die kompilierte Version der Site kann ohne den Quellcode auf einem Produktionsserver bereitgestellt werden.

Zurück nach oben

Hintergrund

Standardmäßig werden ASP.NET-Webseiten und Codedateien dynamisch kompiliert, wenn eine Ressource wie die Seite einer Website zum ersten Mal durch einen Benutzer angefordert wird. Nachdem Seiten und Codedateien zum ersten Mal kompiliert wurden, werden die kompilierten Ressourcen zwischengespeichert. Aus diesem Grund sind nachfolgende Anforderungen derselben Seite sehr effizient.

ASP.NET kann auch eine gesamte Site vorkompilieren, bevor sie den Benutzern zugänglich gemacht wird. ASP.NET bietet für das Vorkompilieren einer Site die folgenden Optionen:

• Direktes Vorkompilieren einer Site. Mit dieser Option können Sie die Leistung vorhandener Sites verbessern und die Sites auf Fehler überprüfen.

• Vorkompilieren einer Site zur Bereitstellung. Diese Option liefert eine besondere Art der Ausgabe, die Sie auf einem Produktionsserver bereitstellen können.

Darüber hinaus können Sie eine Site vorkompilieren, um sie schreibgeschützt oder aktualisierbar zu machen. Die folgenden Abschnitte enthalten weitere Details zu den Optionen.

Direktes Vorkompilieren

Sie können die Leistung der Website durch Vorkompilierung verbessern. Das gilt insbesondere für Sites mit häufigen Änderungen und Erweiterungen von ASP.NET-Webseiten und Codedateien. Die Zeit, die für das dynamische Kompilieren von neuen und geänderten Seiten erforderlich ist, könnte beim Benutzer zu einer negativen Einschätzung bezüglich der Qualität der Site führen.

Die direkte Vorkompilierung entspricht vom Vorgang her gänzlich der Kompilierung, die bei der Anforderung einer Seite durch einen Benutzer durchgeführt wird. Die Leistungssteigerung wird also vor allem dadurch erzielt, dass die Seiten nicht erst bei der ersten Anforderung kompiliert werden.

Bei der direkten Vorkompilierung werden alle ASP.NET-Dateitypen kompiliert. (HTML-Dateien, Grafiken und andere statische Nicht-ASP.NET-Dateien bleiben unverändert.) Bei der Vorkompilierung wird dieselbe Logik verwendet wie bei der dynamischen Kompilierung, d. h. die Abhängigkeiten zwischen Dateien werden berücksichtigt. Bei der Vorkompilierung werden vom Compiler Assemblys für den ausführbaren Anteil der Ausgabe erstellt und in einem speziellen Ordner im Verzeichnis %SystemRoot%\Microsoft.NET\Framework\Version\Temporary ASP.NET Files gespeichert. Spätere Seitenanforderungen erfüllt ASP.NET dann durch den Rückgriff auf die Assemblys in diesem Ordner.

Wenn Sie die Site erneut vorkompilieren, werden nur neue oder geänderte Dateien kompiliert (oder Dateien mit Abhängigkeiten gegenüber neuen oder geänderten Dateien). Durch diese Compileroptimierung können Sie die Site bei kleineren Aktualisierungen ohne großen Aufwand kompilieren.

Vorkompilieren für die Bereitstellung

Durch Vorkompilieren der Site lässt sich eine ausführbare Version der Site erstellen, die Sie auf einem Produktionsserver bereitstellen können. Beim Vorkompilieren für die Bereitstellung wird als Ausgabe ein Layout erstellt. Das Layout enthält Assemblys, Konfigurationsinformationen, Informationen zu den Siteordnern sowie statische Dateien (z. B. HTML-Dateien und Grafiken).

Nach dem Kompilieren der Site können Sie das Layout auf einem Produktionsserver bereitstellen. Verwenden Sie dazu beispielsweise den XCopy-Befehl von Windows, FTP, die Windows-Installation usw. Das bereitgestellte Layout fungiert dann als Site, und ASP.NET erfüllt die Seitenanforderungen durch den Rückgriff auf die Assemblys in diesem Layout.

Das Vorkompilieren einer Site für die Bereitstellung ist auch eine Schutzmaßnahme für den Quellcode und anderes geistiges Eigentum. Weitere Informationen zum Umgang des Compilers mit Dateien bei der Kompilierung für die Bereitstellung finden Sie unter Behandlung von Dateien bei der Sitekompilierung für die Bereitstellung weiter unten in diesem Thema.

Es gibt zwei Arten des Vorkompilierens für die Bereitstellung: Vorkompilieren nur für die Bereitstellung und Vorkompilieren für die Bereitstellung und die Aktualisierung.

Vorkompilieren nur für die Bereitstellung

Beim Vorkompilieren nur für die Bereitstellung erstellt der Compiler Assemblys aus praktisch allen ASP.NET-Quelldateien, die normalerweise zur Laufzeit kompiliert werden. Dazu gehört Programmcode in Seiten, CS- und VB-Klassendateien, anderen Codedateien und Ressourcendateien. Die Compilerausgabe enthält keine Quelldaten und kein Markup mehr. Im entstandenen Layout werden für jede der ASPX-Dateien kompilierte Dateien generiert (mit der Erweiterung .compiled). Diese enthalten Zeiger zu der entsprechenden Assembly für die Seite.

Um eine Website einschließlich des Layouts der Seiten zu ändern, müssen Sie die Originaldateien ändern, die Site neu kompilieren und das Layout erneut bereitstellen. Die einzige Ausnahme ist die Sitekonfiguration. Sie können Änderungen an der Datei Web.config auf dem Produktionsserver vornehmen, ohne dass Sie die Site neu kompilieren müssen.

Diese Option bietet den wirksamsten Schutz für ASP.NET-Webseiten und eine hohe Leistung beim Erstzugriff.

Vorkompilieren für die Bereitstellung und die Aktualisierung

Beim Vorkompilieren für die Bereitstellung und die Aktualisierung verwendet der Compiler für das Erstellen der Assemblys den gesamten Quellcode (außer den Seitencode von Seiten, die aus nur einer Datei bestehen) und sonstige Dateien, die normalerweise Assemblys erstellen (z. B. Ressourcendateien). Der Compiler konvertiert ASPX-Dateien in einzelne Dateien, die das Code-Behind-Modell verwenden, und kopiert sie in das Layout.

Mit dieser Option können Sie nach der Kompilierung eingeschränkte Änderungen an den ASP.NET-Webseiten der Site vornehmen. Sie können z. B. die Anordnung der Steuerelemente, die Farben, Schriftsätze und sonstige Darstellungseigenschaften von Seiten ändern. Sie können auch Steuerelemente hinzufügen, sofern diese keine Ereignishandler oder anderen Code erfordern.

Beim ersten Ausführen der Site führt ASP.NET weitere Kompilierungsschritte durch, um aus dem Markup eine Ausgabe zu erstellen.

Hinweis:
Auf einer vorkompilierten aktualisierbaren Site ist der Verweis mehrerer Seiten auf die gleiche CodeFile-Klasse nicht zulässig.

Entscheidungsmatrix für die Vorkompilierung

Anhand der folgenden Tabelle können Sie das zu verwendende Kompilierungsmodell auswählen. Einige der Optionen, die in der Tabelle aufgeführt sind, werden weiter unten in diesem Thema beschrieben.

Ziel	Kompilierungsmodell
Schnelles Entwickeln von Anwendungen, ohne sich mit der Kompilierung von Code befassen zu müssen.	Verwenden der Standardkompilierung (keine Vorkompilierung).
Verkürzen der Antwortzeit für die erste Seitenanforderung an die Website.	Verwenden der direkten Vorkompilierung oder einer der Optionen für die Bereitstellungskompilierung.
Quellcode und Benutzeroberflächencode getrennt.	Verwenden der Vorkompilierung mit aktualisierbarer Benutzeroberfläche.
Ändern des Benutzeroberflächencodes, ohne den Quellcode zu ändern.	Verwenden der Vorkompilierung mit aktualisierbarer Benutzeroberfläche.
Entfernen des gesamten Quellcodes und Benutzeroberflächencodes vom Produktionsserver.	Verwenden der Vorkompilierung mit nicht aktualisierbarer Benutzeroberfläche.
Aktualisieren der Anwendung durch das Ersetzen bestimmter Assemblys.	Verwenden der Vorkompilierung mit festen Namen.
Erhöhen der Sicherheit der Anwendung durch Verwendung von Assemblys mit starken Namen.	Verwenden der Vorkompilierung mit signierten Assemblys.

Ausführen der Vorkompilierung

Sie können eine Website durch Verwendung des Tools Aspnet_compiler.exe über die Befehlszeile vorkompilieren. Weitere Informationen finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites für die Bereitstellung und ASP.NET-Kompilierungstool (Aspnet_compiler.exe). Visual Studio enthält auch Befehle zum Vorkompilieren einer Website über die IDE.

Hinweis:
Das Vorkompilieren einer Website kompiliert nur diese Site, keine untergeordneten Sites. Wenn eine Webseite einen in IIS als Anwendung markierten Unterordner enthält, wird die untergeordnete Anwendung beim Vorkompilieren des übergeordneten Ordners nicht kompiliert.

Für Sites, die mit aktiviertem Quellschutz kompiliert werden sollen, gilt beim Vorkompilieren einer Website eine Codierungseinschränkung. Eine Basisseitenklasse (Code-Behind-Klasse) kann auf eine zugeordnete Seitenklasse (ASPX-Datei) und Seitenklassenmember verweisen, indem ein vollqualifizierter Klassenname verwendet wird. Diese Art von Verweis funktioniert jedoch nicht, wenn die Vorkompilierung der Site mit aktiviertem Quellschutz durchgeführt wurde. Das liegt daran, dass sich die Basisseitenklasse der Code-Behind-Datei nicht in der gleichen Assembly befindet wie die Seitenklasse, die aus der ASPX-Seite abgeleitet wurde. Weitere Informationen zur Vorkompilierung mit aktiviertem Quellschutz finden Sie unter Gewusst wie: Signieren von Assemblys für vorkompilierte Websites.

Standardkompilierung

Sie müssen eine ASP.NET-Anwendung nicht manuell kompilieren. ASP.NET kompiliert die Webanwendung standardmäßig bei der ersten Anforderung einer Seite der Anwendung durch einen Webbrowser. Wenn Sie eine Datei der Anwendung ändern, bestimmt die ASP.NET-Laufzeit bei der nächsten Anforderung einer Seite die Abhängigkeiten für die geänderte Datei. Es werden nur die Dateien neu kompiliert, die von der Änderung betroffen sind.

Vorteile

Die Verwendung der Standardkompilierung bietet folgende Vorteile:

• Einfache Verwendung. Der ASP.NET-Compiler führt alle Schritte automatisch für Sie aus.

• Das optimale Kompilierungsmodell während der Entwicklung, wenn die Entwicklung durch die zusätzlichen Schritte, die für die Vorkompilierung einer Website erforderlich sind, verlangsamt wird.

Nachteile

Die Verwendung der Standardkompilierung weist folgende Nachteile auf:

• Kann bei der ersten Anforderung der Website zu erheblichen Verzögerungen führen.

• Erfordert das Speichern von Quellcodedateien auf dem Produktionsserver.

• Macht Quellcode und Benutzeroberflächencode für jede Person verfügbar, die über Dateisystemzugriff auf das Websiteverzeichnis auf dem Server verfügt.

Verwendungsmöglichkeiten für die Standardkompilierung

Verwenden Sie Standardkompilierung in den folgenden Situationen:

• Beim Entwickeln und Testen einer Website.

• Für Websites mit überwiegend statischen Informationen.

• Für Websites, die selten geändert werden.

• Wenn Sie keine Einwände gegen das Speichern von Quellcodedateien auf dem Produktionsserver haben.

Direkte Kompilierung

Sie können eine Site vorkompilieren, die sich bereits auf einem Produktionsserver befindet. Dies wird als direkte Kompilierung bezeichnet. Wenn Sie eine Datei in der Anwendung ändern, können Sie die betroffenen Dateien mit dem ASP.NET-Kompilierungstool neu kompilieren. Die betroffenen Dateien werden auch bei der nächsten Anforderung einer Seite von der Anwendung neu kompiliert.

Weitere Informationen über dieses Kompilierungsmodell finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites.

Vorteile

Die Verwendung der direkten Kompilierung bietet folgende Vorteile:

• Die Antwortzeit bei der ersten Anforderung von der Website wird verringert.

• Es sind keine speziellen Bereitstellungsschritte erforderlich. Die Anwendung wird auf genau die gleiche Weise wie bei der Anforderung einer Seite von der Site kompiliert.

Nachteile

Die Verwendung der direkten Kompilierung weist folgende Nachteile auf:

• Der gesamte Quellcode für die Anwendung muss auf dem Produktionsserver gespeichert werden.

• Macht Quellcode und Benutzeroberflächencode für jede Person verfügbar, die auf das Websiteverzeichnis zugreifen kann.

Verwendungsmöglichkeiten für die direkte Kompilierung

Verwenden Sie die direkte Kompilierung in den folgenden Situationen:

• Sie nehmen häufig Änderungen an Seiten auf der Website vor.

• Sie haben keine Einwände gegen das Speichern von Quellcodedateien auf dem Produktionsserver.

• Sie möchten die Antwortzeit für die ersten Seitenanforderungen optimieren.

Vorkompilieren mit aktualisierbarer Benutzeroberfläche

Indem Sie den Schalter -u des ASP.NET-Kompilierungstools verwenden, können Sie Quellcode (CS-, VB- und RESOURCE-Dateien) in eine DLL kompilieren. Sie können das Benutzeroberflächenmarkup in den ASPX-Dateien lassen, damit es für Aktualisierungen verfügbar ist. Nach der Bereitstellung der Website auf einem Produktionsserver kann der ASPX-Code geändert werden, ohne die gesamte Website neu kompilieren zu müssen.

Weitere Informationen über dieses Kompilierungsverfahren finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites für die Bereitstellung.

Vorteile

Das Vorkompilieren einer Website mit aktualisierbarer Benutzeroberfläche bietet folgende Vorteile:

• Die Antwortzeit bei der ersten Anforderung von der Website wird verringert.

• Benutzeroberflächenentwickler können Darstellung und Verhalten einer Website ändern, ohne dass die gesamte Website neu kompiliert werden muss.

• Es ist Schutz für Ihr geistiges Eigentum im Quellcode der Anwendung vorhanden. Das geistige Eigentum ist vor einer zufälligen Einsichtnahme durch Personen geschützt, die über Dateisystemzugriff auf das Websiteverzeichnis verfügen.

Nachteile

Das Vorkompilieren einer Website mit aktualisierbarer Benutzeroberfläche hat folgende Nachteile:

• Erfordert vor der Bereitstellung auf Produktionsservern einen besonderen Kompilierungsschritt.

• Geistiges Eigentum in der Benutzeroberfläche der Anwendung (ASPX-Dateien) ist für alle verfügbar, die über Zugriff auf das Websiteverzeichnis verfügen.

• Mehrere Seiten können nicht auf die gleiche CodeFile-Klasse verweisen, bei der es sich um die zugeordnete Codedatei für eine Seite handelt, die das Code-Behind-Modell verwendet.

Verwendungsmöglichkeiten für das Vorkompilieren mit aktualisierbarer Benutzeroberfläche

Sie sollten eine Anwendung mit aktualisierbarer Benutzeroberfläche in den folgenden Situationen vorkompilieren:

• Benutzeroberflächenentwickler arbeiten von Quellcodeentwicklern getrennt.

• Der Quellcode des Programms umfasst geistiges Eigentum, das Sie vor einer zufälligen Einsichtnahme schützen möchten.

• Sie möchten den Quellcode des Programms nicht auf dem Produktionsserver speichern.

Vorkompilieren mit nicht aktualisierbarer Benutzeroberfläche

Das ASP.NET-Kompilierungstool kann den gesamten Quellcode für eine Anwendung in DLLs kompilieren, die im Verzeichnis Bin der Anwendung bereitgestellt werden. Dazu gehören Benutzeroberflächendateien wie ASPX- und ASCX-Dateien.

Weitere Informationen über dieses Kompilierungsverfahren finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites für die Bereitstellung.

Vorteile

Das Vorkompilieren mit nicht aktualisierbarer Benutzeroberfläche bietet folgende Vorteile:

• Die Antwortzeit bei der ersten Anforderung von der Website wird verringert.

• Es ist Schutz für Ihr geistiges Eigentum im Quellcode und Benutzeroberflächencode der Anwendung vorhanden. Das geistige Eigentum ist vor einer zufälligen Einsichtnahme durch Personen geschützt, die Zugriff auf das Websiteverzeichnis verfügen.

Nachteile

Das Vorkompilieren mit nicht aktualisierbarer Benutzeroberfläche weist folgende Nachteile auf:

• Erfordert vor der Bereitstellung auf Produktionsservern einen besonderen Kompilierungsschritt.

• Auch geringfügige Änderungen der Benutzeroberfläche der Anwendung erfordern die erneute Kompilierung der gesamten Website.

Verwendungsmöglichkeiten für das Vorkompilieren mit nicht aktualisierbarer Benutzeroberfläche

Sie sollten die Website mit nicht aktualisierbarer Benutzeroberfläche in den folgenden Situationen vorkompilieren:

• Der Benutzeroberflächencode umfasst geistiges Eigentum, das Sie vor einer zufälligen Einsichtnahme schützen möchten.

• Sie müssen die Benutzeroberfläche nicht häufig ändern.

• Auf dem Produktionsserver sollen sich nur kompilierte DLLs befinden.

Vorkompilieren zu Assemblys mit festen Namen

Das ASP.NET-Kompilierungstool verwendet für die Assemblys Namen, die während der Kompilierung nach dem Zufallsprinzip generiert werden. Der Name der Assembly ändert sich bei jedem erneuten Kompilieren der Anwendung.

Da sich die Assemblynamen ändern, müssen Sie die gesamte Anwendung erneut bereitstellen, um eine Assembly zu verarbeiten. Wenn Sie jedoch den -fixednames-Schalter in Verbindung mit dem ASP.NET-Kompilierungstool verwenden, können Sie für jede Seite der Anwendung eine Assembly erstellen. Der Name der Assembly wird bei nachfolgenden Kompilierungen nicht geändert. Daher können Sie Service Releases der Anwendung erstellen, die nur die geänderten Assemblys ersetzen.

Da durch die Verwendung des -fixednames-Schalters für jede Seite eine einzelne Assembly erstellt wird, sollten Sie die Anzahl der Seiten in der Anwendung begrenzen.

Weitere Informationen über dieses Vorkompilierungsverfahren finden Sie unter Gewusst wie: Generieren von festen Namen mit dem ASP.NET-Kompilierungstool.

Vorteile

Das Vorkompilieren zu Assemblys mit festen Namen bietet folgende Vorteile:

• Die Namen der einzelnen Assemblys bleiben zwischen den Kompilierungen unverändert. Daher können Sie bestimmte Assemblys ersetzen, ohne die gesamte Anwendung erneut bereitstellen zu müssen.

• Geringfügige Aktualisierungen der Anwendung können gezielter durchgeführt werden.

Nachteile

Das Vorkompilieren zu Assemblys mit festen Namen weist folgende Nachteile auf:

• Für jede Seite in der Anwendung wird eine Assembly erstellt. Auf diese Weise können viele Assemblys für Sites erstellt werden, die viele Seiten aufweisen.

Verwendungsmöglichkeiten für das Vorkompilieren zu Assemblys mit festen Namen

Sie sollten eine Website in der folgenden Situation zu Assemblys mit festen Namen vorkompilieren:

• Sie müssen Webanwendungen bearbeiten, ohne die gesamte Anwendung zu ersetzen.

Vorkompilieren zu signierten Assemblys

Mit dem ASP.NET-Kompilierungstool können Sie Assemblys mit starken Namen erstellen, die im globalen Assemblycache (GAC) des Servers oder im Verzeichnis Bin der Anwendung bereitgestellt werden können. Durch die Verwendung einer signierten Assembly wird es böswilligen Benutzern erschwert, die Assemblys einer Anwendung durch bösartigen Code zu ersetzen.

Weitere Informationen über dieses Kompilierungsverfahren finden Sie unter Gewusst wie: Signieren von Assemblys für vorkompilierte Websites.

Vorteile

Das Vorkompilieren zu signierten Assemblys bietet folgende Vorteile:

• Signierte Assemblys erhöhen die Sicherheit der Anwendung, da das Ersetzen von Assemblys durch bösartigen Code erschwert wird.

Nachteile

Das Vorkompilieren zu signierten Assemblys weist folgende Nachteile auf:

• Die Verwaltung von Schlüsseln in gemeinsam verwendeten Entwicklungsumgebungen kann komplex sein.

• Assemblys müssen über das AllowPartiallyTrustedCallersAttribute-Attribut verfügen, das von der ASP.NET-Laufzeit aufgerufen werden muss.

Verwendungsmöglichkeiten für das Vorkompilieren zu signierten Assemblys

Sie sollten eine Website in den folgenden Situationen zu signierten Assemblys vorkompilieren:

• Benutzer können auf das Anwendungsverzeichnis oder den GAC zugreifen, und sie können die Assemblys der Anwendung ersetzen.

• Sie möchten die Möglichkeit für Dritte einschränken, die vom Anwendungscode generierten Assemblys zu ersetzen.

Schreiben der bei der Vorkompilierung entstehenden Ausgabe

Nachdem der Vorkompilierungsprozess abgeschlossen ist, wird die erzeugte Ausgabe in einen von Ihnen angegebenen Ordner geschrieben. Sie können die Ausgabe in jeden verfügbaren Ordner im Dateisystem schreiben, indem Sie FTP (File Transfer Protocol) oder HTTP verwenden. Sie müssen dabei über die entsprechenden Berechtigungen zum Schreiben auf die Zielsite verfügen.

Hinweis:
Der Veröffentlichungsprozess stellt nur die Dateien bereit, die in den Websiteordnern und deren Unterordnern enthalten sind. Die Datei Machine.config wird nicht bereitgestellt. Unter Umständen unterscheidet sich also die Konfiguration des Zielwebservers von der Konfiguration Ihres Computers, was sich möglicherweise auf das Verhalten der Anwendung auswirkt.

Sie können einen Zielordner auf einem Stagingserver oder einem Produktionsserver angeben. Sie können die Ausgabe auch in einen Ordner auf dem lokalen Computer schreiben. Wenn Sie einen Order auf einem Produktionsserver angeben, können Sie Veröffentlichung und Bereitstellung in einem Schritt durchführen. Wenn Sie die Ausgabe in einen Ordner schreiben, der nicht zu einer Website gehört, können Sie die Ausgabe in einem separaten Schritt auf den Server kopieren.

Hinweis:
Wenn Sie eine vorkompilierte Website mit Visual Studio öffnen, können Sie die Website nicht erstellen. Die Buildoptionen sind deaktiviert. Zum Ändern der Site wird empfohlen, die Dateien in der ursprünglichen Website zu bearbeiten, die Website vorzukompilieren und sie dann erneut zu veröffentlichen.

Die beim Kompilierungsprozess entstehende Ausgabe umfasst die kompilierten Assemblys für sämtlichen Code und für alle Seiten. Wenn Sie per Option festlegen, dass die vorkompilierte Site aktualisiert werden kann, werden sämtliche Code-Behind-Klassen für die ASPX-Dateien, ASMX-Dateien und ASHX-Dateien zu Assemblys kompiliert. Die ASPX-Dateien, ASMX-Dateien und ASHX-Dateien selbst werden jedoch unverändert in den Zielordner kopiert, sodass Sie nach der Bereitstellung der Site weiterhin Änderungen am Layout vornehmen können. Bei vorkompilierten Sites, die aktualisiert werden können, wird der in Einzeldateiseiten enthaltene Code nicht zu einer Assembly kompiliert. Stattdessen wird er als Quellcode bereitgestellt.

Statische Dateien werden nicht kompiliert. Stattdessen werden sie unverändert in den Ausgabeordner kopiert. Die statischen Dateien umfassen Grafiken, HTM-Dateien und HTML-Dateien, Textdateien und Ähnliches. Weitere Informationen finden Sie weiter unten in diesem Thema unter Behandlung von Dateien bei der Sitekompilierung für die Bereitstellung.

Während der Vorkompilierung eventuell auftretende Fehler werden im Ausgabefenster und im Fenster Fehlerliste angezeigt. Wenn während der Vorkompilierung ein Fehler auftritt, kann die Site nicht vollständig kompiliert werden und wird nicht veröffentlicht.

Dateibehandlung bei der ASP.NET-Vorkompilierung

Beim Vorkompilieren einer Site für die Bereitstellung erstellt ASP.NET ein Layout, d. h. eine Struktur, die die Compilerausgabe enthält. Dieser Abschnitt beschreibt die Dateibehandlung bei der Vorkompilierung sowie Struktur und Inhalt des Layouts.

Sie können entweder eine Kombination aus Quellcode (Dateien, die eine Assembly erstellen, einschließlich Programmcode und Ressourcen) und Markup (ASPX-Dateien) oder nur Quellcode vorkompilieren.

Kompilierte Dateien

Beim Vorkompilierungsprozess werden Aktionen mit verschiedenen Dateitypen in einer ASP.NET-Webanwendung ausgeführt. Die Behandlung der Dateien unterscheidet sich abhängig davon, ob die Anwendung nur für die Bereitstellung oder für Bereitstellung und Aktualisierung vorkompiliert wird.

Hinweis:

Wenn eine Website nur für die Bereitstellung bzw. für die Bereitstellung und die Aktualisierung vorkompiliert wird, werden die Datei-Zugriffssteuerungslisten (Access Control Lists, ACLs) für Zieldateien und Unterverzeichnisse nicht beibehalten. Wenn Sie beispielsweise zuvor eine Website vorkompiliert und an einem Zielspeicherort bereitgestellt, die Zugriffssteuerungsliste einer Datei geändert und die Website anschließend erneut vorkompiliert und bereitgestellt haben, gehen die Änderungen der Zugriffssteuerungsliste verloren.

In der folgenden Tabelle werden die unterschiedlichen Dateitypen sowie die Aktionen beschrieben, die mit diesen Dateitypen bei der Vorkompilierung für die Bereitstellung durchgeführt werden.

Dateitypen	Vorkompilierungsaktion	Ausgabeverzeichnis
ASPX, ASCX, MASTER	Generiert Assemblys und eine COMPILED-Datei, die auf die Assembly zeigt. Die ursprüngliche Datei verbleibt als Platzhalter zum Erfüllen von Anforderungen an ihrem Ort.	Assemblys und COMPILED-Dateien werden in den Ordner Bin geschrieben. Seiten (ASPX-Dateien, ohne Inhalt) verbleiben an ihrem ursprünglichen Speicherort.
.asmx, .ashx	Generiert Assemblys. Die ursprüngliche Datei verbleibt als Platzhalter zum Erfüllen von Anforderungen an ihrem Ort.	Ordner Bin
Dateien im Ordner App_Code	Generiert eine oder mehrere Assemblys (je nach Web.config-Einstellungen). Hinweis: Statischer Inhalt im Ordner App_Code wird nicht in den Zielordner kopiert.	Ordner Bin
.CS-Dateien oder VB-Dateien, die sich nicht im Ordner App_Code befinden	Werden mit der Seite oder der davon abhängigen Ressource kompiliert.	Ordner Bin
DLL-Dateien im Ordner Bin.	Kopiert Dateien unverändert.	Ordner Bin
Ressourcendateien (.resx)	Generiert für RESX-Dateien, die in den Ordnern App_LocalResources und App_GlobalResources gefunden werden, eine oder mehrere Assemblys sowie eine Kulturstruktur.	Ordner Bin
Dateien im Ordner App_Themes (einschließlich Unterordnern)	Es werden am Zielort Assemblys generiert. Außerdem werden COMPILED-Dateien generiert, die auf die Assemblys zeigen.	Bin
Statische Dateien (HTM-Dateien, HTML-Dateien, JS-Dateien, Grafikdateien usw.)	Kopiert Dateien unverändert.	Gleiche Struktur wie in der Quelle.
Browserdefinitionsdateien	Kopiert Dateien unverändert. Hinweis: Die Browserinformationen werden von den Konfigurationsdateien auf Computerebene geerbt. Dies führt unter Umständen zu einem anderen Verhalten auf dem Zielserver.	App_Browsers
Abhängige Projekte	Die Ausgabe des abhängigen Projekts wird in eine Assembly generiert.	Ordner Bin
Web.config-Dateien	Kopiert Dateien unverändert.	Gleiche Struktur wie in der Quelle.
Global.asax-Dateien	Generiert eine Assembly.	Ordner Bin

In der folgenden Tabelle werden die unterschiedlichen Dateitypen sowie die Aktionen beschrieben, die mit diesen Dateitypen durchgeführt werden, wenn die Anwendung für die Bereitstellung und Aktualisierung vorkompiliert wird.

Dateitypen	Vorkompilierungsaktion	Ausgabeverzeichnis
ASPX, ASCX, MASTER	Generiert Assemblys für Dateien, die Code-Behind-Klassendateien aufweisen. Generiert eine COMPILED-Datei, die auf die Assembly zeigt. Einzeldateiversionen dieser Dateien werden unverändert an den Zielort kopiert.	Assemblys und COMPILED-Dateien werden in den Ordner Bin geschrieben.
.asmx, .ashx	Kopiert Dateien unverändert, ohne sie zu kompilieren.	Gleiche Struktur wie in der Quelle.
Dateien im Ordner App_Code	Generiert eine oder mehrere Assemblys (je nach Web.config-Einstellungen). Hinweis: Statischer Inhalt im Ordner App_Code wird nicht in den Zielordner kopiert.	Ordner Bin
CS-Dateien oder VB-Dateien, die sich nicht im Ordner App_Code befinden	Werden mit der Seite oder der davon abhängigen Ressource kompiliert.	Ordner Bin
DLL-Dateien im Ordner Bin.	Kopiert Dateien unverändert.	Ordner Bin
Ressourcendateien (.resx)	Generiert für RESX-Dateien in den App_GlobalResources-Ordnern eine oder mehrere Assemblys sowie eine Kulturstruktur. RESX-Dateien in den App_LocalResources-Ordnern werden unverändert in den Ordner App_LocalResources im Ausgabeverzeichnis kopiert.	Assemblys werden im Ordner Bin gespeichert.
Dateien im Ordner App_Themes (einschließlich Unterordnern)	Kopiert Dateien unverändert.	Gleiche Struktur wie in der Quelle.
Statische Dateien (HTM-Dateien, HTML-Dateien, JS-Dateien, Grafikdateien usw.)	Kopiert Dateien unverändert.	Gleiche Struktur wie in der Quelle.
Browserdefinitionsdateien	Kopiert Dateien unverändert. Hinweis: Die Browserinformationen werden von den Konfigurationsdateien auf Computerebene geerbt. Dies führt unter Umständen zu einem anderen Verhalten auf dem Zielserver.	App_Browsers
Abhängige Projekte	Die Ausgabe des abhängigen Projekts wird in eine Assembly generiert.	Ordner Bin
Web.config-Dateien	Kopiert Dateien unverändert.	Gleiche Struktur wie in der Quelle.
Global.asax-Dateien	Generiert eine Assembly.	Ordner Bin

COMPILED-Dateien

Für ausführbare Dateien in einer ASP.NET-Webanwendung fügt der Compiler den Namen von Assemblys und Dateien die Dateinamenerweiterung COMPILED hinzu. Der Assemblyname wird vom Compiler generiert. Die COMPILED-Datei enthält keinen ausführbaren Code. Stattdessen enthält sie nur die Informationen, die ASP.NET für das Auffinden der entsprechenden Assembly benötigt.

Nach dem Bereitstellen der vorkompilierten Anwendung verwendet ASP.NET die Assemblys im Ordner Bin, um Anforderungen zu bearbeiten. Die Vorkompilierungsausgabe enthält als Platzhalter für Seiten ASPX- und ASMX-Dateien. Die Platzhalterdateien enthalten keinen Code. Sie sind nur vorhanden, um für eine bestimmte Seitenanforderung ASP.NET aufzurufen. Mithilfe der Platzhalterdateien können Sie außerdem Dateiberechtigungen so festlegen, dass sie den Zugriff auf Seiten einschränken.

Aktualisieren von vorkompilierten Websites

Nach dem Bereitstellen einer vorkompilierten Website können Sie nur in begrenztem Maße Änderungen an den Dateien in der Site vornehmen. Die folgende Tabelle beschreibt die Auswirkungen von verschiedenen Arten von Änderungen.

Dateityp	Änderungen sind zulässig (nur Bereitstellung)	Änderungen sind zulässig (Bereitstellung und Aktualisierung)
Statische Dateien (HTM-Dateien, HTML-Dateien, JS-Dateien, Grafikdateien usw.)	Statische Dateien können geändert, entfernt oder hinzugefügt werden. Wenn eine ASP.NET-Webseite auf geänderte oder entfernte Seiten oder Seitenelemente verweist, treten möglicherweise Fehler auf.	Statische Dateien können geändert, entfernt oder hinzugefügt werden. Wenn eine ASP.NET-Webseite auf geänderte oder entfernte Seiten oder Seitenelemente verweist, treten möglicherweise Fehler auf.
ASPX-Datei	Änderungen an vorhandenen Seiten sind nicht zulässig. Es dürfen keine neuen ASPX-Dateien hinzugefügt werden.	Sie können das Layout von ASPX-Dateien ändern und Elemente hinzufügen, die keinen Code erfordern, z. B. HTML-Elemente oder ASP.NET-Serversteuerelemente ohne Ereignishandler. Sie können auch neue ASPX-Dateien hinzufügen, die bei der ersten Anforderung kompiliert werden.
SKIN-Dateien	Änderungen und neue SKIN-Dateien werden ignoriert.	Änderungen und neue SKIN-Dateien sind zulässig.
Web.config-Dateien	Änderungen, die die Kompilierung von ASPX-Dateien betreffen, sind zulässig. Kompilierungsoptionen für das Debuggen oder die Batchverarbeitung werden ignoriert. Änderungen an Profileigenschaften oder Anbieterelementen sind nicht zulässig.	Änderungen sind nur erlaubt, wenn die Site- bzw. Seitenkompilierung nicht davon betroffen ist. Dies schließt Compilereinstellungen, Vertrauensebenen und Globalisierung ein. Änderungen, die die Kompilierung betreffen oder das Verhalten in kompilierten Seiten ändern, werden ignoriert oder lösen in einigen Fällen möglicherweise Fehler aus. Andere Änderungen sind zulässig.
Browserdefinitionen	Änderungen und neue Dateien sind zulässig.	Änderungen und neue Dateien sind zulässig.
Aus Ressourcendateien (RESX-Dateien) kompilierte Assemblys	Neue Ressourcenassemblydateien können sowohl für globale als auch für lokale Ressourcen hinzugefügt werden.	Neue Ressourcenassemblydateien können sowohl für globale als auch für lokale Ressourcen hinzugefügt werden.

Codebeispiele

Gewusst wie: Vorkompilieren von ASP.NET-Websites für die Bereitstellung

Gewusst wie: Signieren von Assemblys für vorkompilierte Websites

Gewusst wie: Erstellen von Assemblys mit Versionsangaben für vorkompilierte Websites

Gewusst wie: Generieren von festen Namen mit dem ASP.NET-Kompilierungstool

Gewusst wie: Konfigurieren von veröffentlichten Websites

Zurück nach oben

Siehe auch

Referenz

ASP.NET-Kompilierungstool (Aspnet_compiler.exe)

Zurück nach oben