Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. |
Übersetzung
Original
|
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 |
|---|
Informationen zum Ermitteln der richtigen Version von "Aspnet_compiler.exe" finden Sie weiter unten in diesem Thema unter Suchen der richtigen Version von "Aspnet_compiler.exe". |
aspnet_compiler [-?]
[-m metabasePath | -v virtualPath [-p physicalPath]]
[[-u] [-f] [-d] [-fixednames] targetDir]
[-c]
[-errorstack]
[-nologo]
[[-keyfile file | -keycontainer container ] [-aptca] [-delaysign]]
|
Option |
Beschreibungen |
|---|---|
|
-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 Option -m 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. Wenn Sie diese Option verwenden, werden Codeblöcke in ASPX-Dateien (das heißt, in script-Elementen oder zwischen <%-Tags und %>-Tags gefundener Code) nicht kompiliert. Wenn es daher Compilerfehler in diesen Codeblöcken gibt, sehen Sie den Fehler erst zur Laufzeit, da die ASPX-Datei erst dann vollständig kompiliert wird. Es ist im Allgemeinen nicht sicher, diese Option für eine Site zu verwenden, die Codeblöcke in ASPX-Dateien benötigt. |
|
-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 Befehlssyntax und Optionen für das Tool an. |
Es gibt zwei Versionen des ASP.NET-Kompilierungstools:
-
Die Version, die zusammen mit .NET Framework 2.0 bereitgestellt wird. Verwenden Sie diese Version für Webanwendungen, die in Anwendungspools bereitgestellt werden, die der .NET Framework 2.0-CLR zugeordnet sind. Die Webanwendungen können auf .NET Framework 2.0, .NET Framework 3.0 oder .NET Framework 3.5 verweisen.
-
Die Version, die zusammen mit .NET Framework 4 bereitgestellt wird. Verwenden Sie diese Version für Webanwendungen, die in Anwendungspools bereitgestellt werden, die der .NET Framework 4-CLR zugeordnet sind. Die Webanwendungen können auf .NET Framework 2.0, .NET Framework 3.0, .NET Framework 3.5 oder .NET Framework 4 verweisen. Wenn diese Version für Websites verwendet wird, die auf .NET Framework 2.0, .NET Framework 3.0 oder .NET Framework 3.5 verweisen, steht im Vergleich zur .NET Framework 2.0-Version eine verbesserte Fehlerberichterstattung zur Verfügung.
Weitere Informationen zum Entwickeln, Kompilieren und Bereitstellen von Websites, die auf bestimmte Versionen von .NET Framework abzielen, finden Sie unter Festlegung von .NET Framework-Zielversionen für ASP.NET-Webprojekte und Übersicht über die parallele Ausführung in ASP.NET. Informationen darüber, wie das ASP.NET-Kompilierungstool bestimmt, auf welche Version von .NET Framework eine Website abzielt, finden Sie unter der BuildManager.TargetFramework-Eigenschaft.
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. |
|
Hinweis
|
|---|
|
Die Kompilierung einer Webanwendung mit Masterseiten kann fehlschlagen, wenn Sie die Anwendung als aktualisierbare Site kompilieren und ein Namenskonflikt auftritt. Ein solcher Konflikt entsteht, wenn der Name der Masterseite mit dem Namen des Namespace für eine Inhaltsseite übereinstimmt, die von der Masterseite abgeleitet wird. (Die Vererbungsbeziehung wird vom Inherits-Attribut der @ Page-Direktive begründet). Um diesen Fehler zu beheben, ändern Sie entweder den Klassennamen der Masterseite bzw. den Namen des Namespace, oder kompilieren Sie die Anwendung als nicht aktualisierbar. |
|
Hinweis
|
|---|
|
Wenn Sie mithilfe der .NET Framework 4-Version des Tools eine Website direkt vorkompilieren und die Site auf eine frühere Version von .NET Framework abzielt und einem Anwendungspool zugeordnet ist, der auf die .NET Framework 2.0-CLR abzielt, verursacht die erste Anforderung an die Webanwendung die dynamische Kompilierung, so als ob die Site nicht vorkompiliert worden wäre. Das liegt daran, dass der Befehlszeilencompiler temporäre Ordner, die nicht von der .NET Framework 2.0-CLR erkannt werden, in .NET Framework 4 kompiliert. |
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 jeweiligen 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. HinweisStatische 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. HinweisDie 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. HinweisStatische 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 Updates 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 Sn.exe (Strong Name-Tool) 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.
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 physischen 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
Das Tool "Aspnet_compiler.exe" wird im Verzeichnis von Microsoft.NET Framework installiert. Wenn auf dem Computer mehrere .NET Framework-Versionen parallel ausgeführt werden, werden unter Umständen mehrere Versionen des Tools installiert. In der folgenden Tabelle sind die Orte aufgeführt, an denen das Tool für andere Versionen von .NET Framework installiert ist.
|
Version von .NET Framework |
Speicherort der Datei "Aspnet_compiler.exe" |
|---|---|
|
.NET Framework, Version 2.0, Version 3.0 und Version 3.5 (32-Bit-Systeme) |
%windir%\Microsoft.NET\Framework\v2.0.50727 |
|
.NET Framework, Version 2.0, Version 3.0 und Version 3.5 (64-Bit-Systeme) |
%windir%\Microsoft.NET\Framework64\v2.0.50727 |
|
.NET Framework, Version 4 (32-Bit-Systeme) |
%windir%\Microsoft.NET\Framework\v4.0.30319 |
|
.NET Framework, Version 4 (64-Bit-Systeme) |
%windir%\Microsoft.NET\Framework64\v4.0.30319 |