ASP.NET-Kompilierungstool (Aspnet_compiler.exe)

Mit dem ASP.NET-Kompilierungstool (Aspnet_compiler.exe) können Sie eine ASP.NET-Webanwendung kompilieren, entweder direkt oder für die Bereitstellung an einem Zielort wie auf einem Produktionsserver. Mit der direkten Kompilierung wird die Anwendungsleistung unterstützt, da Endbenutzer bei der ersten Anwendungsanforderung während der Kompilierung der Anwendung nicht auf Verzögerungen stoßen.

Die Kompilierung für die Bereitstellung kann auf zwei Wegen durchgeführt werden. Entweder werden alle Quelldateien wie Code-Behind-Dateien und Markupdateien entfernt, oder die Markupdateien werden beibehalten.

Hinweis

Das ASP.NET-Kompilierungstool ist erst ab ASP.NET, Version 2.0, verfügbar.

aspnet_compiler  [-?]
                 [-m metabasePath | -v virtualPath [-p physicalPath]]
                 [[-u] [-f] [-d] [-fixednames] targetDir]
                 [-c]
                 [-errorstack]
                 [-nologo]
                 [[-keyfile file | -keycontainer container ] [-aptca] [-delaysign]]

Optionen

Option	Beschreibung
-m metabasePath	Gibt den vollständigen zu kompilierenden IIS-Metabasispfad der Anwendung an. Die IIS-Metabasis ist ein hierarchischer Informationsspeicher zur Konfigurierung von IIS. Beispielsweise ist der Metabasispfad zur Standard-IIS-Website LM/W3SVC/1/ROOT. Diese Option kann nicht mit der -v-Option oder der -p-Option kombiniert werden.
-v virtualPath	Gibt den virtuellen Pfad der zu kompilierenden Anwendung an. Wenn -p ebenfalls angegeben wird, wird der Wert des zugehörigen physicalPath-Parameters dazu verwendet, die zu kompilierende Anwendung zu suchen. Sonst wird die IIS-Metabasis verwendet, und das Tool geht davon aus, dass die Quelldateien unter der Standard-Website, die im Metabasisknoten LM/W3SVC/1/ROOT angegeben ist, gespeichert sind. Diese Option kann nicht mit der -m-Option kombiniert werden.
-p physicalPath	Gibt den vollständigen Netzwerkpfad oder den lokalen Datenträgerpfad des Stammverzeichnisses an, das die zu kompilierende Anwendung enthält. Wenn -p nicht angegeben wird, wird für die Suche nach dem Verzeichnis die IIS-Metabasis verwendet. Diese Option muss mit der -v-Option kombiniert werden. Sie kann jedoch nicht mit der -m-Option kombiniert werden.
-u	Gibt an, dass Aspnet_compiler.exe eine vorkompilierte Anwendung erstellen soll, die nachfolgende Aktualisierungen von Inhalten wie ASPX-Seiten ermöglicht. Wenn diese Option fehlt, enthält die entstehende Anwendung nur kompilierte Dateien und kann auf dem Bereitstellungsserver nicht aktualisiert werden. Sie können die Anwendung nur aktualisieren, indem Sie die Quellmarkupdateien ändern und erneut kompilieren. Der targetDir-Parameter muss enthalten sein.
-f	Gibt an, dass das Tool vorhandene Dateien im Verzeichnis targetDir und in seinen Unterverzeichnissen überschreiben soll.
-d	Überschreibt die in den Quellkonfigurationsdateien der Anwendung festgelegten Einstellungen, um das Einfügen von Debuginformationen in die kompilierte Anwendung zu erzwingen. Andernfalls erfolgt keine Debugausgabe. Sie können die -d-Option nicht für die direkte Kompilierung verwenden. Bei der direkten Kompilierung werden Konfigurationseinstellungen für Debugoptionen berücksichtigt.
targetDir	Der Netzwerkpfad oder der lokale Datenträgerpfad zum Stammverzeichnis, der die kompilierte Anwendung enthält. Wenn der targetDir-Parameter nicht enthalten ist, wird die Anwendung direkt kompiliert.
-c	Gibt an, dass die zu kompilierende Anwendung vollständig neu erstellt werden soll. Komponenten, die bereits kompiliert wurden, werden erneut kompiliert. Wenn diese Option fehlt, erstellt das Tool nur die Teile der Anwendung, die seit der letzten Kompilierung geändert wurden.
-errorstack	Gibt an, dass das Tool bei fehlgeschlagener Kompilierung der Anwendung Stapelüberwachungsinformationen berücksichtigen soll.
-keyfile file	Gibt an, dass AssemblyKeyFileAttribute auf die kompilierte Assembly angewendet werden soll. Das Attribut gibt den Namen der Datei an, die das öffentliche/private Schlüsselpaar für die Generierung eines starken Namens enthält. Diese Option muss mit der -aptca-Option kombiniert werden. Wenn das Attribut bereits in Codedateien auf die Assembly angewendet wird, löst Aspnet_compiler.exe eine Ausnahme aus.
-keycontainer container	Gibt an, dass AssemblyKeyNameAttribute auf die kompilierte Assembly angewendet werden soll. Das Attribut gibt den Namen des Containers für das öffentliche/private Schlüsselpaar zur Generierung eines starken Namens an. Diese Option muss mit der -aptca-Option kombiniert werden. Wenn das Attribut bereits in Codedateien auf die Assembly angewendet wird, löst Aspnet_compiler.exe eine Ausnahme aus.
-aptca	Gibt an, dass das AllowPartiallyTrustedCallersAttribute, das nicht voll vertrauenswürdigen Aufrufern Zugriff auf eine Assembly gewährt, auf die von Aspnet_compiler.exe generierte Assembly mit starkem Namen angewendet werden soll. Diese Option muss mit der -keyfile-Option oder der -keycontainer-Option kombiniert werden. Wenn das Attribut bereits in Codedateien auf die Assembly angewendet wird, löst Aspnet_compiler.exe eine Ausnahme aus.
-delaysign	Legt fest, dass AssemblyDelaySignAttribute auf die generierte Assembly angewendet werden soll. Das Attribut gibt an, dass eine Assembly statt mit dem öffentlichen/privaten Schlüsselpaar nur mit dem öffentlichen Schlüsseltoken signiert werden soll. Diese Option muss mit der -keyfile-Option oder der -keycontainer-Option kombiniert werden. Wenn das Attribut bereits in Codedateien auf die Assembly angewendet wird, löst Aspnet_compiler.exe eine Ausnahme aus. Wenn Sie die -delaysign-Option verwenden, kann der von Aspnet_compilier.exe erzeugte Code ausgeführt werden, bevor der Code signiert ist. Sie müssen sicherstellen, dass der Code nicht von böswilligen Benutzern missbraucht werden kann, bevor die Signierung abgeschlossen ist.
-fixednames	Gibt an, dass für jede Seite in der Anwendung eine Assembly generiert werden soll. Jede Assembly wird mit dem virtuellen Pfad der Originalseite benannt, sofern der Name nicht die Beschränkung des Betriebssystems für Dateinamen überschreitet. In diesem Fall wird ein Hash generiert und für den Assemblynamen verwendet. Sie können die -fixednames-Option nicht für die direkte Kompilierung verwenden. Bei der direkten Kompilierung werden Konfigurationseinstellungen für den Batchkompilierungsmodus berücksichtigt.
-nologo	Unterdrückt die Copyrightmeldung.
-?	Zeigt die Befehlssyntax und die Optionen für das Tool an.

Hinweise

Bei der Verwendung des ASP.NET-Kompilierungstools gibt es allgemein zwei Möglichkeiten: die direkte Kompilierung und die Kompilierung für die Bereitstellung, bei der ein Zielausgabeverzeichnis angegeben wird. In den folgenden Abschnitten werden diese Szenarien beschrieben.

Direktes Kompilieren einer Anwendung

Das ASP.NET-Kompilierungstool kann eine Anwendung direkt kompilieren, d. h., es ahmt das Erstellen mehrerer Anforderungen an die Anwendung nach, was zu einer ständigen Kompilierung führt. Bei Benutzern einer vorkompilierten Site tritt keine Verzögerung auf, die bei der ersten Anforderung durch die Seitenkompilierung verursacht wird.

Beachten Sie, dass beim Verwenden eines imitierten Kontos sowohl das Konto als auch das Anmeldebenutzerkonto Schreibzugriff auf das Ziel haben müssen, damit die Vorkompilierung erfolgreich durchgeführt werden kann.

Wenn Sie eine Site direkt vorkompilieren, gilt Folgendes:

• Die Site behält ihre Dateien und ihre Verzeichnisstruktur.

• Auf dem Server müssen sich Compiler für alle von der Site verwendeten Programmiersprachen befinden.

• Wenn die Kompilierung einer Datei fehlschlägt, schlägt die Kompilierung der gesamten Site fehl.

Sie können nach dem Hinzufügen neuer Quelldateien eine Anwendung erneut direkt kompilieren. Sofern Sie nicht die -c-Option einschließen, kompiliert das Tool nur die neuen oder geänderten Dateien.

Hinweis

Bei der Kompilierung einer Anwendung, die eine geschachtelte Anwendung enthält, wird die geschachtelte Anwendung nicht kompiliert. Die geschachtelte Anwendung muss separat kompiliert werden.

Kompilieren einer Anwendung für die Bereitstellung

Sie kompilieren eine Anwendung für die Bereitstellung (Kompilierung zu einem Zielort), indem Sie den targetDir-Parameter angeben. Der endgültige Speicherort für die Webanwendung kann targetDir sein. Die kompilierte Anwendung kann jedoch auch weiter bereitgestellt werden.

Mithilfe der -u-Option wird die Anwendung so kompiliert, dass Sie an bestimmten Dateien in der Anwendung Änderungen vornehmen können, ohne die Anwendung neu zu kompilieren. Aspnet_compiler.exe unterscheidet statische und dynamische Dateitypen und behandelt diese beim Erstellen der entstehenden Anwendung unterschiedlich.

Statische Dateitypen besitzen keinen zugehörigen Compiler oder Buildanbieter, wie z. B. Dateien mit den Dateinamenerweiterungen .css, .gif, .htm, .html, .jpg, .js und so weiter. Diese Dateien werden einfach in den Zielort kopiert, und ihre jeweilige Positionen in der Verzeichnisstruktur werden beibehalten.

Dynamische Dateitypen haben einen zugehörigen Compiler oder Buildanbieter. Zu ihnen gehören Dateien mit ASP.NET-spezifischen Dateinamenerweiterungen wie .asax, .ascx, .ashx, .aspx, .browser, .master und so weiter. Das ASP.NET-Kompilierungstool generiert aus diesen Dateien Assemblys. Wenn die -u-Option fehlt, erstellt das Tool auch Dateien mit der Dateinamenerweiterung .COMPILED, die ihrer Assembly die ursprünglichen Quelldateien zuordnen. Um die Erhaltung der Verzeichnisstruktur der Anwendungsquelle sicherzustellen, generiert das Tool in den entsprechenden Speicherorten in der Zielanwendung Platzhalterdateien.

Wenn Sie angeben möchten, dass der Inhalt der kompilierten Anwendung geändert werden kann, müssen Sie die -u-Option verwenden. Andernfalls werden nachfolgende Änderungen ignoriert oder verursachen Laufzeitfehler.

In der folgenden Tabelle wird beschrieben, wie das ASP.NET-Kompilierungstool verschiedene Dateitypen behandelt, wenn die -u-Option berücksichtigt wird.

Dateityp	Compileraktion
.ascx, .aspx, .master	Diese Dateien werden in Markup und Quellcode aufgeteilt, der Code-Behind-Dateien einschließt. Der Quellcode wird in Assemblys kompiliert, deren Namen von einem Hashalgorithmus abgeleitet sind. Die Assemblys werden im Verzeichnis Bin abgelegt. Sämtlicher Inlinecode, d. h. Code zwischen <script runat="server">-Elementen, ist im Markup enthalten und wird nicht kompiliert. Neue Dateien mit demselben Namen wie die Quelldateien werden so erstellt, dass sie das Markup enthalten, und sie werden in den entsprechenden Ausgabeverzeichnissen abgelegt.
.ashx, .asmx	Diese Dateien werden nicht kompiliert und unverändert und unkompiliert in die Ausgabeverzeichnisse verschoben. Wenn Sie den Handlercode kompilieren möchten, legen Sie den Code in Quellcodedateien im Verzeichnis App_Code ab.
.cs, .vb, .jsl, .cpp (ohne Code-Behind-Dateien für die zuvor aufgelisteten Dateitypen)	Diese Dateien werden kompiliert und als Ressource in Assemblys, die auf sie verweisen, eingefügt. Quelldateien werden nicht in das Ausgabeverzeichnis kopiert. Wenn auf eine Codedatei nicht verwiesen wird, wird sie nicht kompiliert.
Benutzerdefinierte Dateitypen	Diese Dateien werden nicht kompiliert. Diese Dateien werden in die entsprechenden Ausgabeverzeichnisse kopiert.
Quellcodedateien im App_Code-Unterverzeichnis	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Hinweis Statische Dateitypen im Verzeichnis App_Code werden nicht in die Ausgabeverzeichnisse kopiert.
RESX-Dateien und RESOURCE-Dateien im App_GlobalResources-Unterverzeichnis	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Im Hauptausgabeverzeichnis wird kein App_GlobalResources-Unterverzeichnis erstellt, und in die Ausgabeverzeichnisse werden keine im Quellverzeichnis gespeicherten RESX- oder RESOURCE-Dateien kopiert. Hinweis Die Ressourcendateien im App_GlobalResources-Unterverzeichnis werden in Assemblys kompiliert, bevor Code im App_Code-Unterverzeichnis kompiliert wird. Die Änderung von Ressourcendateien nach der Kompilierung wird nicht unterstützt.
RESX-Dateien und RESOURCE-Dateien im App_LocalResources-Unterverzeichnis	Diese Dateien werden nicht kompiliert und in die entsprechenden Ausgabeverzeichnisse kopiert.
SKIN-Dateien im App_Themes-Unterverzeichnis	Die SKIN-Dateien und statische Designdateien werden nicht kompiliert und in die entsprechenden Ausgabeverzeichnisse kopiert.
.browser Web.config Statische Dateitypen Bereits im Verzeichnis Bin vorhandene Assemblys	Diese Dateien werden unverändert in die Ausgabeverzeichnisse kopiert.

In der folgenden Tabelle wird beschrieben, wie das ASP.NET-Kompilierungstool verschiedene Dateitypen behandelt, wenn die -u-Option fehlt.

Hinweis

Sie werden nicht durch Warnungen daran gehindert, den Quellcode einer kompilierten Anwendung zu ändern.

Dateityp	Compileraktion
.aspx, .asmx, .ashx, .master	Diese Dateien werden in Markup und Quellcode geteilt, was sowohl Code-Behind-Dateien und sämtlichen in <script runat="server">-Elementen enthaltenen Code umfasst. Der Quellcode wird in Assemblys kompiliert, deren Namen von einem Hashalgorithmus abgeleitet werden. Die entstehenden Assemblys werden im Verzeichnis Bin abgelegt. Sämtlicher Inlinecode, d. h. Code zwischen den <% und %>-Klammern, ist im Markup enthalten und wird nicht kompiliert. Der Compiler erstellt neue Dateien, in denen das Markup mit demselben Namen wie die Quelldateien enthalten ist. Die entstehenden Dateien werden im Verzeichnis Bin abgelegt. Außerdem erstellt der Compiler Dateien mit demselben Namen wie die Quelldateien, aber mit der Erweiterung .COMPILED, in denen Zuordnungsinformationen enthalten sind. Die COMPILED-Dateien werden in den Ausgabeverzeichnissen abgelegt, die dem ursprünglichen Speicherort der Quelldateien entsprechen.
.ascx	Diese Dateien werden in Markup und Quellcode geteilt. Quellcode wird in Assemblys kompiliert, deren Namen von einem Hashalgorithmus abgeleitet werden, und im Verzeichnis Bin abgelegt. Es werden keine Markupdateien generiert.
.cs, .vb, .jsl, .cpp (ohne Code-Behind-Dateien für die zuvor aufgelisteten Dateitypen)	Quellcode, auf den von Assemblys verwiesen wird, die aus Dateien vom Typ .ascx, .ashx oder .aspx generiert wurden, wird in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Es werden keine Quelldateien kopiert.
Benutzerdefinierte Dateitypen	Diese Dateien werden wie dynamische Dateien kompiliert. Je nachdem, auf welchem Dateityp sie basieren, kann der Compiler Zuordnungsdateien in den Ausgabeverzeichnissen ablegen.
Dateien im App_Code-Unterverzeichnis	Quellcodedateien in diesem Unterverzeichnis werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Hinweis Statische Dateitypen im Verzeichnis App_Code werden nicht in die Ausgabeverzeichnisse kopiert.
Dateien im App_GlobalResources-Unterverzeichnis	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Im Hauptausgabeverzeichnis wird kein App_GlobalResources-Unterverzeichnis erstellt. Wenn die Konfigurationsdatei appliesTo="All" angibt, werden RESX-Dateien und RESOURCES-Dateien in die Ausgabeverzeichnisse kopiert. Wenn auf sie von einem BuildProvider verwiesen wird, werden sie nicht kopiert.
RESX-Dateien und RESOURCE-Dateien im App_LocalResources-Unterverzeichnis	Diese Dateien werden in Assemblys mit eindeutigen Namen kompiliert und im Verzeichnis Bin abgelegt. In die Ausgabeverzeichnisse werden keine RESX-Dateien oder RESOURCE-Dateien kopiert.
SKIN-Dateien im App_Themes-Unterverzeichnis	Designs werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Stub-Dateien werden für SKIN-Dateien erstellt und im entsprechenden Ausgabeverzeichnis abgelegt. Statische Dateien (z. B. .css) werden in die Ausgabeverzeichnisse kopiert.
.browser Web.config Statische Dateitypen Bereits im Verzeichnis Bin vorhandene Assemblys	Diese Dateien werden unverändert in das Ausgabeverzeichnis kopiert.

Feste Assemblynamen

Für einige Szenarien, z. B. die Bereitstellung einer Webanwendung über MSI Windows Installer, ist es notwendig, konsistente Dateinamen und Inhalte sowie konsistente Verzeichnisstrukturen zu verwenden, um für Aktualisierungen Assemblys und Konfigurationseinstellungen zu identifizieren. In solchen Fällen können Sie mit der -fixednames-Option angeben, dass das ASP.NET-Kompilierungstool, statt mehrere Seiten in Assemblys zu kompilieren, für jede Quelldatei eine Assembly kompilieren soll. Das kann jedoch zu einer großen Zahl an Assemblys führen. Daher sollten Sie diese Option im Interesse der Skalierbarkeit mit Vorsicht verwenden.

Kompilierung mit starkem Namen

Es stehen die Optionen -aptca, -delaysign, -keycontainer und -keyfile zur Verfügung, damit Sie mithilfe von Aspnet_compiler.exe Assemblys mit starkem Namen erstellen können, ohne separat Strong Name-Tool (Sn.exe) zu verwenden. Diese Optionen entsprechen jeweils AllowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute und AssemblyKeyFileAttribute. Da jede Option das entsprechende Attribut auf die kompilierte Assembly anwendet und weil die Attribute mit AttributeUsageAttribute markiert sind, dessen AllowMultiple-Eigenschaft auf false festgelegt ist, führt die Anwendung dieser Schlüssel auf bereits mit einem dieser Attribute markierten Quellcode zum Fehlschlagen der Kompilierung.

Zugeordnete ASP.NET-Klassen

Mehrere Klassen im System.Web.Compilation-Namespace ermöglichen Ihrem Code den Zugriff oder Aufruf von Aspnet_compiler.exe außerhalb der IIS-Umgebung. Die ClientBuildManager-Klasse stellt die PrecompileApplication-Methode für die Kompilierung einer Anwendung bereit. Die ClientBuildManager-Klasse verwendet zudem die ClientBuildManagerParameter-Klasse. Dadurch ist es möglich, PrecompilationFlags anzugeben, die den von diesem Tool verwendeten Optionen entsprechen. Außerdem können Schlüssel für starke Namen angegeben werden.

Beispiele

Mit dem folgenden Befehl wird die WebApplication1-Anwendung direkt kompiliert:

Aspnet_compiler -v /WebApplication1

Der folgende Befehl kompiliert die WebApplication1-Anwendung direkt, und das Tool fügt Stapelüberwachungsinformationen hinzu, wenn es Fehlerberichte erstellen muss.

Aspnet_compiler -v /WebApplication1 -errorstack

Mit dem folgenden Befehl wird die Anwendung WebApplication1 über den physikalischen Verzeichnispfad für die Bereitstellung kompiliert. Außerdem werden den Ausgabeassemblys zwei Attribute hinzugefügt. Die -keyfile-Option wird verwendet, um ein AssemblyKeyFileAttribute-Attribut hinzuzufügen. Das Attribut gibt an, dass die Datei Key.sn die Informationen des öffentlichen/privaten Schlüsselpaars enthält, mithilfe derer das Tool die generierten Assemblys mit starken Namen benennen soll. Außerdem verwendet der Befehl die -aptca-Option, um den generierten Assemblys ein AllowPartiallyTrustedCallersAttribute-Attribut hinzuzufügen. Die kompilierte Webanwendung wird im Verzeichnis c:\applicationTarget erstellt.

Aspnet_compiler -v /WebApplication1 -p "c:\Documents and Settings\Default\My Documents\MyWebApplications\WebApplication1" -keyfile "c:\Documents and Settings\Default\My Documents\Key.sn" -aptca c:\applicationTarget

Mit dem folgenden Befehl wird der Dienst WebService2 unter dem Standardmetabasispfad kompiliert, wobei das Zielverzeichnis SampleWebService mit der kompilierten Anwendung überschrieben wird.

Aspnet_compiler -m /LM/W3SVC/1/ROOT/WebService2 -f c:\InetPub\wwwroot\SampleWebService

Siehe auch

Referenz

.NET Framework-Tools
Strong Name-Tool (Sn.exe)
ASP.NET IIS-Registrierungstool (Aspnet_regiis.exe)
AssemblyKeyFileAttribute
AssemblyKeyNameAttribute
AssemblyDelaySignAttribute
AllowPartiallyTrustedCallersAttribute

Konzepte

Verzögertes Signieren einer Assembly
Assemblys mit starkem Namen