Kapitel 4: Übersetzungsvorgang und Verbreitung

Während der Programmcode in klassischen ASP-Seiten interpretiert wird, kommen in ASP.NET Compiler zum Einsatz.

Grundlagen des Kompilierungsmodells

Das Kompilierungsmodell ist dabei seit ASP.NET 2.0 noch etwas komplexer als in ASP.NET 1.x, weil die Anforderung entstanden ist, dass in der Hintergrundcodeklasse kein vom Designer generierter Code enthalten sein soll. In ASP.NET 1.x musste dort jedes Steuerelement, das in der .aspx-Seite verwendet wurde, als Protected-Mitglied deklariert sein, damit der Programmcode in der Hintergrundcodeklasse die Mitglieder nutzen konnte. Visual Studio .NET 2002 / 2003 gelang es dabei nicht immer, die Steuerelemente und die Deklarationen konsistent zu halten. Außerdem machte das Modell das gemeinsame Arbeiten eines Layouters an der .aspx-Seite und eines Entwicklers an der Hintergrundcodedatei schwierig.

Ab ASP.NET 2.0 werden diese Protected-Mitglieder nun zur Übersetzungszeit aus der .aspx-Seite generiert. Die .aspx-Seite wird nicht wie bisher in genau eine Klasse umgewandelt, sondern es entstehen zwei Klassen:

Die erste Klasse (name_aspx) ist eine als partiell deklarierte Klasse. Sie enthält für jedes Serversteuerelement eine Protected-Mitgliederdeklaration. Diese Klasse bildet den Gegenpart zu der Klasse in der Hintergrundcodedatei (ebenfalls name_aspx), die daher auch immer als partiell deklariert sein muss.
In der zweiten Klasse (name_aspx) erzeugt das ASP.NET Page Framework Quellcode für alle HTML- und Server-Tags in der .aspx-Seite, d. h., der komplette Tag-Code wird in Programmcode umgesetzt. Diese Klasse erbt von der ersten Klasse und damit auch von dem in der Hintergrundcodedatei enthaltenen Gegenstück.

Da die Hintergrundcodeklasse von der in der FCL implementierten Basisklasse System.Web.UI.Page erbt, erbt folglich also indirekt auch die Klasse_name_aspx von der Page-Klasse. Die Klasse name_aspx wird dann in eine DLL übersetzt und kann von dem Webserver zur Erzeugung der Ausgabe an den Client aufgerufen werden.

Abbildung 4.7 Übersetzungsvorgang einer ASP.NET-Webseite

Autokompilierung

In Visual Studio .NET 2002 / 2003 wurden alle Hintergrundcodeklassen und eigenständigen Codedateien immer zur Entwicklungszeit in eine einzige .dll-Datei kompiliert. Diese Funktion entfällt im VWD: Der dortige Übersetzungsvorgang hat nur die Aufgabe, die Kompilierbarkeit zur Entwicklungszeit zu prüfen. Daher ist die Entwicklungskompilierung einer Webanwendung im VWD optional.

Das Standardübersetzungsmodell ab ASP.NET 2.0 ist die Kompilierung beim ersten Aufruf einer Website (Auto-Kompilierung, Ad-hoc-Kompilierung). ASP.NET 2.0 / 3.5 erzeugen pro Webseite eine Assembly beim ersten Aufruf. Alle Klassen, die nicht Hintergrundcodeklassen sind (also die Klassen im Verzeichnis /App_Code), werden in eine einzige separate Assembly kompiliert, sobald die erste Webseite in der Anwendung aufgerufen wird.

Präkompilierung

Das ASP.NET Page Framework 2.0 / 3.5 unterstützt die Möglichkeit, eine komplette ASP.NET-Webanwendung inklusive der .aspx-Seiten zur Entwicklungszeit zu kompilieren und in diesem kompilierten Zustand auszuliefern. Die Präkompilierung erzeugt wahlweise

eine DLL-Assembly für die gesamte Webanwendung oder
eine DLL-Assembly für jede Webseite und eine DLL-Assembly für jede in /App_Code verwendete Programmiersprache.

Außerdem entsteht eine neue Konfigurationsdatei PrecompiledApp.config.

Eine weitere Option betrifft die Auslieferung der .aspx-Dateien. Der Entwickler hat die Wahl:

Die Webanwendung wird präkompiliert und die Inhalte der .aspx-Dateien werden zusätzlich mit ausgeliefert, sodass diese auf dem Zielsystem noch geändert werden können, wodurch eine Ad-hoc-Neukompilierung der geänderten Seite angestoßen würde. In der Wortwahl von ASP.NET 2.0 / 3.5 heißt diese Option Aktualisierbare, präkompilierte Webanwendung.
Die Webanwendung wird präkompiliert und die Inhalte der .aspx-Dateien werden nicht an das Zielsystem übergeben. Der Empfänger kann also das Layout nicht ändern. Dies ist die beste Option zum Schutz des geistigen Eigentums und zum Schutz vor ungewollten Eingriffen der Empfänger. In der Wortwahl von ASP.NET 2.0 / 3.5 heißt diese Option Nicht aktualisierbare, präkompilierte Webanwendung. Auch die ASPX-Dateien sind noch in der Ausgabe enthalten, jedoch fehlt der eigentliche Code. Stattdessen enthalten alle Dateien nur noch den Satz: »This is a marker file generated by the precompilation tool, and should not be deleted!«. Die .aspx-Dateien dienen also dem Webserver nur als Markierungsdateien und zur Aufrechterhaltung der NTFS-Dateisystemrechte.

Der VWD stellt die Präkompilierung im Menüpunkt Erstellen/Website veröffentlichen (Build/Publish Website) bereit (gilt leider nicht für Visual Web Developer Express). Im Gegensatz dazu kopiert Website/Website kopieren (Website/Copy WebSite) nur Dateien auf ein Zielsystem oder einen Zielpfad. Bei der Nutzung von Erstellen/Website veröffentlichen style='letter-spacing:-.1pt'> lässt sich über das Kontrollkästchen Aktualisierbarkeit dieser vorkompilierten Site zulassen (Allow this precompiled website to be updateable) die Aktualisierbarkeit steuern.

An der Kommandozeile kann das Werkzeug aspnet_compiler.exe verwendet werden.

Der nachfolgende Befehl kompiliert den Inhalt eines Verzeichnisses im Dateisystem und speichert das Ergebnis in einem anderen Verzeichnis.

aspnet_compiler -v -c -p H:\WWW\WorldWideWings\WebUI_CSVB\
H:\WWW\WorldWideWings\WebUI_CSVB_Compiled –f -u

In der nachstehenden Variante wird als Quelle ein IIS-Anwendungsverzeichnis verwendet.

aspnet_compiler /v /LM/W3SVC/1/Root/WebUI_CSVB H:\WWW\WorldWideWings\WebUI_CSVB_Compiled –f -u

Die Option –f bedeutet, dass ein eventuell vorhandener Inhalt des Zielverzeichnisses überschrieben wird. Die Option –u steuert die Aktualisierbarkeit.

Verbreitung von Anwendungen

Aus den vorgenannten Kompilierungsoptionen ergeben sich nachstehende Optionen für die Auslieferung einer Anwendung (Deployment):

Auto-Compilation: Die Anwendung wird komplett mit allen Dateien (auch den Hintergrundcodedateien und Dateien in /App_Code) auf das Zielsystem kopiert und dort beim ersten Aufruf übersetzt.
Pre-Compilation: Es werden nur der Inhalt des /bin-Verzeichnisses, die .aspx-, .ascx-, .asmx- und .asax-Dateien, die .config-Dateien sowie alle statischen Inhalte kopiert.

TIPP
Wenn Sie eine präkompilierte ASP.NET 2.0 / 3.5-Webseite aufrufen und dann nur die Meldung »This is a marker file generated by the precompilation tool, and should not be deleted!« sehen, haben Sie in der IIS-Konfiguration für dieses Web versehentlich die ASP.NET-Versionen 1.0 oder 1.1 ausgewählt. Nur ASP.NET 2.0 / 3.5 kann diese Dateien verarbeiten.

Programmiersprachen

An dem komplexen Kompilierungsvorgang können Sie bereits erkennen, dass nicht jede .NET-Programmiersprache für ASP.NET verwendet werden kann, da neben dem Kommandozeilencompiler auch noch die Codegenerierung gewährleistet sein muss. Im .NET Framework 3.5 stellt Microsoft die Sprachen VB und C# zur Verfügung. Die ursprünglichen Pläne, auch C++ / CLI für Webprojekte zur Verfügung zu stellen, wurden nicht realisiert.

Während in ASP.NET 1.x in Visual Studio nur genau eine Programmiersprache pro Projekt erlaubt war, kann ab ASP.NET 2.0 aufgrund der getrennten Kompilierung nun jedes Webform eine andere Sprache verwenden.

HINWEIS
Es ist aber nicht möglich, die Sprache innerhalb eines Webforms zu wechseln. Sofern in der .aspx-Seite Inline-Programmcode zum Einsatz kommt, muss die dort verwendete Programmiersprache der in der Hintergrundcodedatei verwendeten Programmiersprache entsprechen.

Der Programmcode in einem Webprojekt, der nicht an ein Webform gebunden ist (also alle eigenständigen Codedateien im /App_Code-Verzeichnis), kann im Standard weiterhin nur eine einzige Sprache verwenden. Hier gibt es aber die Option, Unterverzeichnisse (mit Namen VB, JS und CS) zu bilden, sodass mehrere Sprachen erlaubt sind. Diese Sprachmischung muss in der web.config-Datei aktiviert werden.

Listing 4.3 Aktivierung der Programmiersprachenmischung in /App_Code

Inhalt dieses Kapitels:

<< Trennung von Layout und Programmcode Steuerelement-Typen >>