ASP.net 2.0 Grundlagen (Stand 2007)

Grundlagen

Was ist ASP.net?

Die Technik oder auch die Programmierung unter ASP.net ist nicht mehr vergleichbar mit den alt bekannten Technologien wie z.B. PHP oder ASP. Bei Beiden genannten Technologien wurde der Code nur "geparsed" und dann seinem Schicksal überlassen, anders bei ASP.net. Um das Prinzip zu verstehen, sollte man die wichtigsten Komponenten kennen. Die wohl wichtigste Komponente ist die Runtime (Common Language Runtime -> CLR) welche den Code der verschiedenen .net Sprachen wie VB.net, C# oder managed C++ in eine Zwischensprache kompiliert, welche u.A. Rechte Anforderungen des Codes überprüft und dann ähnlich wie Java, in einer eigenen Umgebung (Laufzeitumgebung/Common Language Runtime - CLR) ablaufen lässt. Dabei kümmert sich die Runtime auch um das Speichermanagement in Form des Garbage Collectors, der einfach ausgedrückt alles im Speicher killt, was nicht mehr benötigt wird. Bei C++ usw.. wäre das noch Aufgabe des Code Autors gewesen.

Eine weitere, wichtige Komponente ist die Framework Class Library, kurz FCL. Diese stellt etliche Klassen, Funktionen, Typen, Interfaces usw.… bereit. Sozusagen der Werkzeugkasten eines Entwicklers. Unterteilt wird die FCL in so genannte Namespaces, in welche sich die einzelnen Klassen organisieren. Jeder Namespace wurde zu einem bestimmten Zweck geschaffen. So ist z.B. der Namespace System.IO für .net sowas wie die FSO Komponente für das klassische ASP, also zuständig für Dateibasierte Operationen wie kopieren, löschen usw. 

ASP.net Applikationen

Grob beschrieben ist eine ASP.net Applikation eine Ansammlung von Dateien in einem Verzeichnis (Applikationsverzeichnis). Diese Dateien haben alle einen bestimmten Zweck in diesem „Applikationsverzeichnis". Da wären z.B. das /bin Verzeichnis, die web.config und global.asax (Der Zweck dieser Elemente in einer Applikation wird später verdeutlicht). Dann gibt es in dieser Applikation noch die .aspx Dateien (Webform genannt - Stand 2007), diese stellen die „Oberfläche" der Applikation dar. Sie geben den generierten HTML Code an den User aus und greifen dabei auf Programmcode zu, der sich in einer .dll Dateien im Bin Verzeichnis befindet (Ausgenommen natürlich In-Line Code direkt in der aspx). Im Ganzen ist eine Applikation aber anzusehen wie eine Art Programm, welches über eigene Applikationsvariablen, Sessionvariablen und globale Ereignisse verfügt. All dies wird in einer solchen Applikation gekapselt. Das alles und noch mehr (für uns erstmal nicht relevante Elemente) ergeben zusammen eine ASP.net Applikation. Auf den nächsten Seiten wird die Struktur im Dateisystem zum leichteren Verständnis noch mal aufgeführt.

Managed & Unmanaged

Managed ist alles, was von der .net Laufzeitumgebung (CLR) ausgeführt und verwaltet wird. Klassischer nativer Code wie z.B. eine com Komponente sind unmanaged d.h. diese läuft nicht innerhalb der .net Runtime und basieren auf nativen Code. Auf unmanged Code kann lediglich aus der Runtime heraus zugegriffen werden, was aber meist im Sharedhosting durch ein entsprechend konfigurierten Thrustlevel verhindert wird.

Assemblies

Eine Assembly ist die Grundeinheit einer .net Anwendung und liegt im Falle von ASP.net in einer .dll im bin Verzeichnis der Applikation vor. Diese enthält den größten Teil des Applikationsprogrammcodes im MSIL (Microsoft Intermediate Language). Außerdem enthält eine Assembly selbst beschreibende Metadaten über Name, Version und Rechte Anforderungen und ist somit im Deployment besser zu handhaben als com. Leider tritt hier auch eines der größten Irrtümer auf. Eine com .dll Datei ist nicht gleichzusetzen mit einer .net dll. Eine .net Assembly .dll Datei kann ohne weiteres zutun eines Administrators im Sharedhosting verwendet werden. Com, also auch unmanaged .dlls wiederum erfordern händisches Sysadmin eingreifen und haben mit einer managed .net Assembly nichts zu tun, trotz der gleichen Dateiendung. Das manuelle Nachinstallieren von com Komponenten wird in fast keinem SharedHosting angeboten, Einige Anbieter wie z.B. 1und1 bieten lediglich vorinstallierte Komponten z.B. aspmail und safileup an.

Neuerungen

Änderungen zum Vorgänger ASP.net 1.1

Neue Features

• Masterpages

  ASP.net Masterpages sind wie Webform Vorlagen. Man definiert in einem Webprojekt eine oder mehrere Masterpages (Dateiendung *.master), die den Rahmen der Seite definieren. In dieser Masterpage können Bereiche definiert werden, sogenannte Contentplaceholder. Wenn nun eine normale Webform Seite über die eigene Page Direktive ("<% @Page ...") und dem Attribut MasterPageFile auf eine dieser Master verweist, kann diese Webform "Unterseite" auf die Contentplaceholder zugreifen und diese mit eigenem Inhalt füllen. Im Browser wird dann aber nur wie vorher auch die Webform Seite (*.aspx) aufgerufen. Das bedeutet, das Designfehler oder Code nun auch in den verknüpften Masterpages gesucht werden muss.

• Neue UserControls in ASP.net 2.0

  Mit asp.net 2.0 gibs einige neue Usercontrols, die vorher nur als kostenpflichtige CustomControls zu haben waren oder z.B. Bestandteil des IE Controls waren. So ist z.B. nun ein TreeView Control vorhanden, das hierarchische Strukturen wie der Windows Explorer anzeigt und dabei z.B. bessere Browserunterstüzung bietet, als die IE Controls. Eine Liste aller Controls gibt es im MSDN.

  Eine Liste der wichtigsten Controls:

  • View/Multiview
  • Wizzard
  • Substitution
  • SiteMapPath
  • Menu
  • Login Control Sammlung zum Anmelden, Useranlegen, Paßwort vergessen Funktion und allgemeiner User Informationsanzeige usw....

• Vorkompilierung

  Mit Visual Studio 2005 ist es nun möglich, auch die Webform Seiten (*.aspx) vor zukompilieren. In dem Fall werden statt der üblichen aspx Files mit HTML und Programmcode nur ein Platzhalterfile generiert. Bestimmt wird dies beim Veröffentlichen mit Visual Studio 2005 (msbuild) mit der Option "Aktualisierbarkeit dieser vorkompilierten Seite zulassen". Wenn diese Option deaktiviert ist, liegen auf dem Space nur .aspx Files mit dem Inhalt "Dies ist eine Markierungsdatei, die vom Vorkompilierungswerkzeug generiert wurde, und sollte nicht gelöscht werden!". Der *ganze* Code liegt somit nun in den Assemblys. Die Express Edition ist dazu nicht in der Lage, ganz im Gegenteil. Der Visual Web Developer packt alle Projektfiles auf den Webspace. Daher gibt es auch keine Option die "Projekt veröffentlichen" heißt sondern nur "Webseite kopieren". Das ist aber leichter zu supporten da so auch die Quell Code Dateien wie .cs oder .vb (je nach Sprache) auf dem Webspace liegen. Im Falle der kompletten Vorkompilierung ist bleibt nur noch der weg über ildasm aus dem .net SDK oder der anderen IL Dekompilern. Aber auch da gibs mit Visual Studio 2005 ein Problem welches der eingebaute Dotfucator darstellen könnte. Der könnte nämlich das dekompilieren verhindern oder zumindest erschweren.

• Webparts

  Die bereits aus Sharepoint bekannten Webparts können nun auch direkt als UserControl eingebunden werden.

• ADO.net 2.0 (Datenbank Framework)

  Eine Liste aller neuen ADO.net Features gibs hier. Das wichtigste für den Support ist aber, das der Zugriff auf Access Datenbanken unter ASP.net nun endlich möglich ist:

  ADO.NET 2.0 liefert zusätzlich mit OracleClient, OleDb und Odbc noch drei weitere Managed Provider. Diese vier Provider wurden erweitert, um sie in teilweise vertrauenswürdigen Umgebungen (Partial Trust) zu verwenden.

2005ér Tools

Vollwertige ASP.net 2.0 Anwendungen können nur mit folgenden Tools geschrieben werden.

• Visual Studio (kostenpflichtig)
• Visual Web Developer 2005 Express (kostenlos: download)

Struktur

Filestruktur / Komponenten einer ASP.net Applikation. Übersicht über die Applikationskomponenten einer ASP.net Applikation

Root

Hauptapplikationsverzeichnis - Beherbergt die Applikationen innerhalb der IIS Site. Eine .net Applikation in einem Applikationsverzeichnis ist ein in sich geschlossener Bereich wobei jede Applikation Ihre eigenen Applikationsereignisse, Variablen usw.… erzeugt und verwaltet, und so von anderen Applikationen kapselt. So könnte in diesem Beispiel die Applikation CorrectSubApplication nicht auf Applikationsereignisse oder Applikationsvariablen der Hauptapplikation zugreifen. 

/bin

Assembly Verzeichnis. Ablage der .dll Assemblys Dateien.

/InCorrectSubApplication

Ein Beispiel für eine falsch angelegte ASP.net Applikation ohne Applikationsverzeichnis. Wird üblicherweise von anderen Programmen als Visual Studio angelegt d.h. nicht als Applikationsverzeichnis. Da eine Applikation Ihre Komponenten steht's im eigenem Root sucht, würden sich in der InCorrectSubApplication/web.config getroffene Einstellungen nicht z.B. auf die in dem Verzeichnis liegende noCodeBehind.aspx auswirken. Lösung: entweder alle .net Komponenten in diesem Verzeichnis wie web.config, /bin usw.… ins Root kopieren oder eine Umwandlung von nCorrectSubApplication in ein Applikationsverzeichnis durchführen. Wie erwähnt, Visual Studio erstellt von sich aus ein entsprechendes Verzeichnis.

/CorrectSubApplication

Ein Beispiel für eine funktionierende Applikation mit Applikationsverzeichnis. Alle Darin enthaltenden .net Komponenten verhalten sich vollkommen autark vom Rest der Instanz.

Web.config

XML Konfigurationsdatei für die aktuelle ASP.net Applikation. (ähnlich php.ini für PHP). Eine Liste der Konfigurationselemente inkl. deren Bedeutung für ASP.net 1.1 findet Ihr hier. Und hier findet Ihr eine Beispiel web.config, wie sie von Visual Studio 2003.net angelegt wird. Im IIS 6 spielt die web.config nur eine Rolle für ASP.net, in der nächsten Version wird diese praktisch die .htaccess des IIS werden denn mit Ihr werden sich dann auch das verhalten von IIS selbst steuern lassen. 

Global.asax

Behandelt Ereignisse, welche im Lebenszyklus der Applikation auftreten. So können bestimmte globale Aktionen im Anwendungs-Lebenszyklus ausgeführt werden z.B. wenn die Applikation startet d.h. zum Beispiel kurz nach dem Upload oder wenn der AppPool recycled wurde. Ebenso kann das Ende einer Applikation „behandelt" werden.

.aspx

Standard ASP.net Datei. Dient bei Verwendung von CodeBehind nur als Frontend. Und beherbergt die Oberfläche für eine ASP.net Applikation d.h. HTML/Java Code und die definitionen für die User und CustomControls. 

.aspx.cs / .aspx.vb

Diese Datei Extension sollte eigentlich nie auf einer Instanz zu sehen sein aber leider kommt dies hin und wieder vor. Diese Dateien enthalten den Programmcode in seiner Ursprünglichen .net Sprache und sind Bestandteil des CodeBehind Prinzip. Also steht .aspx.cs für C# und aspx.vb für Visual Basic .net. Dieser Code befindet sich nach der Übersetzungsprozedur in der Assembly und sollte (Richtiges Deployment vorausgesetzt) bei Nutzung von Visual Studio nicht auf die Instanz gelegt werden, aber der Vollständigkeit halber hier mit aufgeführt. Webmatrix schreibt übrigens nur Inlinecode d.h. der C# und VB Code werden direkt in das .aspx File geschrieben. Anders beim Quasi Nachfolger Visual Web Developer Express Edition, dieser kann keine Assemblys erzeugen, arbeitet aber mit Codebehind. Hierbei liegen die .aspx.cs / .aspx.vb Files immer auf dem Webspace.

Stellt ein Benutzersteuerelement dar, welche einfach ausgedrückt als eine Art HTML Template mit Programmcode fungieren. Diese Dateien enthalten eine @Control Direktive (meinst in der 1. Zeile), über die individuelle Einstellungen für diese Datei getroffen werden können, ähnlich bzw. teilw. Identisch mit der @Page Direktive.

.master

Frontendseite einer Masterpage. Im Prinzip gleich wie eine normale .aspx Datei mit dem Unterschied, dass hier statt einer Page Direktive eine Master Direktive vorhanden ist.

Deployment

Deployment oder auch Upload und Einrichtung einer ASP.net Applikation im Shared Hosting

Eine .net Applikation benötigt im eigenem Root Verzeichnis eine web.config und optional auch eine global.asax. Vererbung aus übergeordneten Verzeichnissen der Applikation ist nicht möglich.

Beispiel
Ich als Kunde lade meine .net Applikation in Verzeichnis /Shop mit einem FTP Programm von seiner lokalen Festplatte ohne weitere Hilfsmittel hoch. Beim Aufruf erscheint ein Applikationsfehler ohne genauere Informationen. Auch das deaktivieren der CustomErrors in der web.config unter /shop zeigt keine genaueren Fehlerinformationen. 

Lösung
Mit VisualStudio/Visual Basic usw... erstellte Applikationen immer über die Funktion „Projekt kopieren" auf den Webspace hochladen. Bei diesem Vorgang wird automatisch von VS ein Applikationsverzeichnis angelegt. Andernfalls, z.B. bei Verwendung von Webmatrix Webfiles benutzen. 

Konfiguration

Hier werden die wichtigsten Elemente der web.config vorgestellt welche man zur Fehlersuche kennen sollte.

Konfigurationsbeispiel
Eine von VisualStudio generierte Beispiel web.config ist zu finden unter: webconfig.htm. Für ASP.net gibt es 2 Konfigurationsdatein, eine globale machine.config und ein Applikationselement mit dem Namen Web.config. Beide sind hierachisch aufgebaute XML Konfigurationsdateien für ASP.net Anwendungen. Die machine.config ist normalerweise für kleine Anwendung nicht so relevant da diese die .net Konfiguration für den ganzen Server enthält und somit für Kunden z.B. im Shared Hosting nicht zugänglich ist. Dennoch sei erwähnt das in dieser Datei die (später noch genauer beschriebenen) Trustlevel konfiguriert sind. Die Hierachy in einer Web.config hat im ungefähren dieses Schema:

                      							
	<configuration> 
		<system.web>
		
		</system.web>
	</configuration>

                    

Die wichtigsten Elemente

<compilation>
Hiermit werden die Optionen für den Compiler definiert. Debug z.B. legt fest, das die Assemblys mit extra Debuginfos kompiliert wird. Das ist z.B. notwendig, um in der Fehlerausgabe eine Codeangabe zu erhalten. Hierdurch wird allerdings auch die Ausführung der Applikation langsamer und die Dateigröße der Assembly wird erhöht. Alternativ kann der Debugmode auch über die Pagedirektive in der einzelnen Seite aktiviert werden. Beispiel:

                        
<%@ Page language="c#" Codebehind="myFile.aspx.cs" AutoEventWireup="false" 
Inherits="namespace.klasse" debug="true” %> 
                      

<trace>
Hiermit kann die Ausgabe und das verhalten des Trace beeinflusst werden. Beispiel:

                        
	<configuration>
		<system.web>
			<trace enabled="false" pageOutput="true" requestLimit="15"/>
		<system.web>
	</configuration>
                          
                      

Alternativ kann der trace auch über die Pagedirektive in der einzelnen Seite aktiviert werden. Beispiel: <%@ Page language="c#" Codebehind="myFile.aspx.cs" AutoEventWireup="false" Inherits="namespace.klasse" trace="true” %>

<sessionState>
Das SessionState Element definiert den Ort, andem die SessionDaten gespeichert werden. Der Default Wert, welchen z.B. VisualStudio setzt, ist „InProc” d.h. die SessionDaten werden im aktuellen Prozesscontext gespeichert. Diese Option wäre im SharedHosting nicht wirklich optimal da durch einen AppPool Recycle alle SessionDaten verloren gehen und dieser wird in regelmäßigen Abständen durchgeführt. Daher wäre das externe speichern der Daten mehr als sinnvol. Dazu gibs den Wert “StateServer” im “mode” Attribut. Dieser stellt bei uns eine default Einstellung dar. Also muss der Kunde lediglich die folgenden Zeilen aus der web.config entfernen oder auskommentieren:

                        
<sessionState
	mode="InProc"
	stateConnectionString="tcpip=127.0.0.1:42424"
	sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
	cookieless="true"
	timeout="20"
/>
                      

Wenn z.B. im Shared Hosting bei 1und1 das SessionState Element nicht überschrieben wird, werden die SessionDaten extern gespeichert und sind von einem Applicationpool Recycle nicht betroffen.

Fehlersuche

Fehlerursachen (Suche mit Debug/Trace) im Shared Hosting - aber ohne Visual Studio Remote Debugging.

Debug / Trace

Bei den folgendem handelt es sich nicht um das eigentliche Debuggen wo man sich direkt an den Prozess hängen kann, sondern eher um die Interpretation vom Fehlern der .net Runtime. Zum richtigem Debuggen mit z.B. Microsoft Visual Studio wären Admin Rechte notwendig und ein Shared Hosting Kunde müsste Visual Studio unter dem gleichem Benutzer betreiben, wie der Worker Process. Beides ist bei den meisten Shared Hosting Anbietern nicht möglich.

Live Umgebungen sind auch keine Entwicklungsumgebungen, das wird leider immer wieder vergessen. 

Exception Definition

Eine kleine Exception Definition

Das Wort Exception wird im folgendem Abschnitt oft fallen, daher hier kurz erläutert. Eine Exception ist wörtlich übersetzt eine Ausnahme und soll ausdrücken, das ein nicht vorgesehener Zustand vorliegt. Exception werden vom Codeautor „geworfen“ und könnten durch ein entsprechendes ExceptionHandling in Form von try/catch Blöcken um den verdächtigen Code herum „aufgefangen“ werden. Die meisten Exceptions, mit welchen Entwickler in Berührung kommen werden von der FCL, dem .net Framework ausgelöst. Zum größten Teil zu finden im Namespace System.Exception.

Beispielanwendung: Wenn man den Wert einer Variable in einem bestimmten Integer (zahlen) Bereich von 5 – 10 halten möchte, kann beim übersteigen eines bestimmten Wert der Variable, ob verändert durch eigenen oder fremden Code, z.B. eine solche Ausnahme ausgelöst werden damit der Konsument des Codes den Fehler entsprechend „behandeln“ kann.

Fehlerursachen finden

ASP.net Fehlerursachen finden mit Bordmitteln

Der Text auf der rechten Seite ist der Standardmäßig von ASP.net ausgegebene Fehler. Hierbei handelt es sich meist um ein Fehler im eigenem Code. Dies kann ein einfacher Syntaxfehler im Code oder z.B. auch eine Security Exception sein, welche z.B. ausgelöst wird, wenn der Code auf Resourcen zugreifen möchte, die per Trustlevel (im Shared Hosting) verboten sind oder z.B. der ASP.net User für die Aktion im Filesystem keine Rechte hat. Da gibs unzählige Möglichkeiten. Um eine genauere Fehlerausgabe zu erhalten, muß nur der von der .net Runtime ausgegebene Hinweiß befolgt werden der besagt, dass das Attribut „mode“ des Elements „customErrors“ auf den Wert „off“ gesetzt werden muss. 

Migration

Diese Rubrik behandelt den Umstieg auf ASP.net 2.0 in einer typischen Sharehosting Umgebung.

Abwaertskompatibilität
ASP.net 2.0 bzw. .net generell ist zu 95% Abwärtskompatibel d.h. CIL Code, der noch mit einem Compiler für z.B. C# ("1.0") generiert wurde, ist im Normalfall ohne Probleme in einer ASP.net 2.0 ohne jegliches zutun lauffähig. [top]

Erkennen, ob eine Site bereits unter ASP.net 2.0 läuft
Manchmal ist es notwendig, zu testen ob eine Site/Server bereits umgestellt wurde. Machen kann man dies in dem man einfach ein 404 provoziert und eine nicht vorhandene aspx Seite aufruft. In der Ausgabe steht dann am Ende des Dokuments die ASP.net Version. Steht aber auch im "X-AspNet-Version" Feld im HTTP Header. Wird die Version nicht ausgegeben, kann auch folgendes Skript verwendet werden:

                      
<% = Environment.Version %>
                    

Einfach die Zeile in ein .aspx File kopieren, hochladen und aufrufen -> fertig. 

IIS Webserver

Microsoft IIS Webserver Allgemein

Allgemeine IIS Probleme

MimeTypes im IIS
Wenn eine vorhandene Datei nicht über HTTP aufgerufen werden kann obwohl diese definitiv auf dem Space im Scope des IIS liegt, könnte dies an einem fehlenden Mimetype für die extension liegen. In dem Fall muss einfach der Site dieser Spezielle Type hinzugefügt werden. Eine Liste der möglichen MimeTypes gibs hier. [top]