ASP.NET Crashkurs - Trace, Debug und Config

Veröffentlicht: 24. Okt 2005
Von Hannes Preishuber

Auszug aus dem Buch "ASP.NET 2.0 Crashkurs - Schnelleinstieg in neue Technologien und Tools" von Hannes Preishuber".

Dieses Buch ist Ihr Schnelleinstieg in die Neuerungen von ASP.NET 2.0. Dabei werden nicht einfach nur neue Features und Möglichkeiten aufgezählt, sondern deren Anwendung in einem sinnvollen praxisnahen Rahmen erläutert. Auch die wichtigsten Grundkonzepte der Programmierung mit ASP.NET werden - soweit wie nötig - thematisiert.

Das Buch ist deswegen sowohl für Programmierer geeignet, die sich über die neuen Möglichkeiten von ASP.NET 2.0 informieren wollen, als auch für erfahrene Entwickler, die einen komprimierten Einstieg in die Webprogrammierung mit ASP.NET 2.0 suchen.

Microsoft Press


Diesen Artikel können Sie dank freundlicher Unterstützung von Microsoft Press auf MSDN Online lesen. Microsoft Press ist ein Partner von MSDN Online.


Zur Partnerübersichtsseite von MSDN Online

Auf dieser Seite

 Trace
 Debug
 IIS-Konfiguration
 Web Site Administrator Tool
 Konfigurations-API
 Kompilierung
 Health Monitoring

Um es mit Ironie zu sagen: Nur Schwächlinge machen Fehler. Natürlich sind wir keine Schwächlinge und machen deshalb keine Fehler. Damit ist Debuggen für uns selbstverständlich überflüssig. Für alle anderen nicht so perfekten Entwickler bringt ASP.NET einiges, was das Leben leichter machen kann.

Wenn nur eine Anwendung auf einem Server läuft, ist es noch ziemlich einfach, diese zu konfigurieren und zu überwachen. Aber speziell in Hosting-Umgebungen ließ ASP.NET bislang einige Wünsche bezüglich Überwachung und Diagnose offen.

Trace

Tracing wurde schon in ASP.NET 1 eingeführt. Damit kann ziemlich detailliert verfolgt werden, was beim Seitenaufbau vor sich geht. Zusätzlich kann man im Code per Trace.Write und Trace.Warn selbst in das Trace-Fenster oder »in mithörende« Trace-Listener schreiben. Dabei ist diese Ausgabe nur aktiv, wenn das Tracing aktiviert ist. Um das zu erreichen, setzen Sie die entsprechenden Einstellungen in der Page-Direktive oder in der web.config.

<%@ Page Language="VB" MasterPageFile="~/all.master" Title="Trace"  Trace="true" %>

Beim Page Tracing wird die Trace-Ausgabe unten an die erzeugte HTML-Seite angehängt.

Trace ausgeben lassen
Abbildung 1: Trace ausgeben lassen

Wenn Tracing in der web.config aktiviert wird, gilt es für alle Seiten. Den Inhalt des so genannten Trace Stacks ruft man im Browser mit Hilfe der Seite Trace.axd auf. Darin sind dann auch mehrere Traces enthalten.

Application Tracing
Abbildung 2: Application Tracing

In dem Element Trace kann mit dem Attribut enabled das Tracing an- und ausgeschaltet werden. Aus Sicherheitsgründen sollte die Ausgabe des Traces nur lokal erreichbar sein. Das erreicht man mit dem Attribut localonly. In der Version 1.x von ASP.NET stoppte das Tracing, wenn die in requestLimit eingestellte Anzahl von Requests erreicht war. Mit dem neu hinzugekommen Attribut mostRecent stehen immer die aktuellsten Traces zum Abruf bereit. Natürlich muss dafür der entsprechende Wert auf true gesetzt sein.

<trace 
enabled="true"
pageOutput="false"
localOnly="true"
mostRecent="true"
requestLimit="50"
traceMode="SortByTime"
writeToDiagnosticsTrace="true" />

Listing 1: Konfiguration von Trace in web.config

Mit dem Attribut writeToDiagnosticsTrace können Trace-Nachrichten, die von System.Diagnostics.Trace erzeugt werden, weiter geroutet werden. So können aus externen Code-Objekten Trace-Nachrichten in die Seite geleitet oder in einen externen Trace Listener umgeleitet werden. Um die Weiterleitung von Traces zu ermöglichen, muss allerdings mit dem Compiler-Switch Trace kompiliert werden. Diese Einstellung kann in der web.config vorgenommen werden.

<system.codedom>
   <compilers>
     <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" 
      type="Microsoft.VisualBasic.VBCodeProvider, System, Version=2.0.3600.0, Culture=neutral, 
      PublicKeyToken=b77a5c561934e089" warningLevel="1" compilerOptions="/d:TRACE" />
  </compilers>
</system.codedom>
<system.diagnostics>
<trace autoflush="true" indentsize="4">
     <listeners>
       <add name="webListener" type="System.Web.WebPageTraceListener, System.Web, Version=2.0.3500.0, 
        Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
    </listeners>
</trace>
</system.diagnostics>

Listing 2:Compiler-Anweisung in web.config um Trace zu aktivieren

Wenn alle Trace-Nachrichten eingegangen sind, wird das Ereignis TraceFinished ausgelöst. Anschließend kann dieses in der Seite behandelt und dort z. B. die Auflistung der Trace-Nachrichten ausgegeben werden. Aber auch ein Weiterreichen an andere Logging-Mechanismen ist denkbar.

Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
   Trace.Warn("MeinTrace", "Start")
   System.Diagnostics.Trace.Write("MeinSystem.Diagnostics.Trace", "mittendrin")
   Trace.Write("MeinTrace", "Ende")
   AddHandler Trace.TraceFinished, AddressOf Me.OnTraceFinished
End Sub
Sub OnTraceFinished(ByVal sender As Object, ByVal e As TraceContextEventArgs)
   Response.Write("<h1>Trace ausgeben</h1>")
   For Each tr As TraceContextRecord In e.TraceRecords
       Response.Write(String.Format("<b>{0}:</b> {1}<br />", tr.Category, tr.Message))
    Next
End Sub

Listing 3: Trace per Code ausgeben

Debug

Der visuelle Debugger von Visual Studio wartet wieder mit einer Menge Verbesserungen auf: Nicht nur Edit & Continue funktionieren wieder so, wie schon in Visual Basic 6.0, sondern auch das Auslesen von Variablen während des Debuggings ist mehr als einfach geworden. Es genügt, mit der Maus auf eine Variable zu zeigen, um dann durch die Objektstruktur zu navigieren. Sogar einzelne Variablen kann man sofort ändern, egal ob es sich um eine einfache String-Variable oder um eine komplexe XML-Struktur handelt.

Der Debugger von Visual Studio 2005
Abbildung 3: Der Debugger von Visual Studio 2005

Der Debugger wird gestartet, indem man in einer ASPX-Seite F5 drückt. Es wird dann ein neues Browserfenster geöffnet. Haltepunkte werden mit F9 gesetzt.

Man kann auch einen aktuellen Prozess an den Debugger anhängen. Dazu wählen Sie im Menü Debug den Punkt Attach to Process aus.

Debug-Prozesse überwachen
Abbildung 4: Debug-Prozesse überwachen

HINWEIS: Häufig werden Fehler beim Debuggen dadurch verursacht, dass das Konto des aktuell angemeldeten Benutzers nicht Mitglied der Debugger-Gruppe ist.

Außerdem muss das Debuggen generell aktiviert sein. Überprüfen Sie dies im Kontextmenü des Projektes im Projektmappen-Explorer mit dem Menüpunkt Property Pages. In Start Options muss die Checkbox bei ASP.NET Debugging gesetzt sein.

Es muss darüber hinaus in der Page-Direktive das Debugging für die Seite mit dem Attribut Debug aktiviert sein. Wenn das Attribut fehlt, ist der Standardwert false, das Debugging also deaktiviert.

<%@ Page Language=»VB«  Debug=»true«%>

IIS-Konfiguration

Erste Anlaufstelle zur Konfiguration der Internet Information Services war schon immer die MMC (Management Console) mit dem entsprechenden IIS-Snap-In. Wenn Sie einen Webserver verwenden, befindet sich der Menüpunkt in Administration Internet-Informationsdienste. Bei Windows XP befindet sich dieselbe Administrationsoberfläche in der Systemsteuerung unter Verwaltung.

Neu hinzugekommen ist dabei der Reiter ASP.NET, unter dem sich die Konfigurationsmöglichkeiten für das Web befinden.

Umstellen der verwendeten ASP.NET-Version
Abbildung 5: Umstellen der verwendeten ASP.NET-Version

Dies funktioniert zu jeder Zeit, also auch nachträglich. Den gleichen Effekt können Sie mit dem Kommandozeilentool aspnet_regiis erzielen. Auf einem Web Server können so problemlos mehrere Versionen von ASP.NET parallel betrieben werden.

In den weiteren Dialogen, die mit der Schaltfläche Edit Configuration aufrufbar sind, können dann weitere Details festgelegt werden. Diese werden ausnahmslos in der web.config der Anwendung gespeichert.

Authentication-Dialog in der MMC
Abbildung 6: Authentication-Dialog in der MMC

Web Site Administrator Tool

Heutzutage lässt sich fast jeder Wireless Access Point per Web-Interface konfigurieren. Da wurde es höchste Zeit, dass auch Webseiten per Web-Administration konfigurierbar werden. Mit ASP.NET 2.0 ist das jetzt möglich.

Der Aufruf kann entweder per Menüpunkt in Visual Studio oder direkt im Web-Browser erfolgen.

Wenn der Aufruf per AXD in dem URL erfolgt, wird eine Umleitung durchgeführt.

Startseite des Web Site Administration Tools
Abbildung 7: Startseite des Web Site Administration Tools

Es gibt drei Bereiche, die konfiguriert werden können. Dabei wird direkt die web.config der Anwendung verändert. Wenn keine web.config vorhanden ist, wird sie beim ersten Aufruf erzeugt.

Das Administration Tool wurde selbst mit ASP.NET 2.0 programmiert und befindet sich samt Source Code im folgenden Verzeichnis:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.xxx\ASP.NETWebAdminFiles

Dabei lässt sich sogar in der Webanwendung selbst per web.config der Website-Administrator konfigurieren.

<webSiteAdministrationTool
            defaultUrl="/aspnet_webadmin/2_0_41231/default.aspx"
            enabled="true"
            errorPage="~/error.aspx"
            localOnly="true"
            requireSSL="false">

Listing 4: Konfiguration des Web Site Administration Tools

Auf der Registerkarte Security lassen sich Benutzer und Rollen anlegen und verwalten. Dazu wurde im Kapitel 6 bereits einiges ausgeführt. Bemerkenswert ist dabei noch die Funktion Manage Access Rules. Damit lassen sich Zugriffsrechte auf Verzeichnisse definieren oder - anders ausgedrückt - Unterverzeichnisse schützen.

Die Sicherheitseinstellungen
Abbildung 8: Die Sicherheitseinstellungen

Die meisten anwendungsspezifischen Einstellungen können im Reiter Application vorgenommen werden. Die Einstellungen zum Versenden von E-Mails werden z. B. von den Login Controls verwendet.

Allgemeine Application Settings
Abbildung 9: Allgemeine Application Settings

Darüber hinaus lässt sich mit der Configuration API jede Einstellung auch programmatisch setzen.

Konfigurations-API

Mit der neuen API können Sie die Möglichkeiten zur Anwendungskonfiguration erweitern. Dies kann für die Installation oder Automatisierung sehr nützlich sein. Dabei muss man nicht direkt XML-Dateien lesen und schreiben. Außerdem muss man sich nicht um Sperren oder den Neustart der Webanwendung kümmern. Natürlich lassen sich damit auch ganze Gruppen von Servern remote-verwalten.

Die API für Webanwendungen befindet sich unter anderem im Namespace System.Web.Configuration in der Klasse WebConfigurationManager. Mit dem Befehl OpenWebConfiguration kann dann eine Konfiguration geöffnet werden. Dabei muss als Parameter der Name im IIS der Webanwendung eingegeben werden. Da es praktisch möglich ist, mehrere virtuelle Web Server zu betreiben, muss eventuell noch die laufende Nummer des Web Servers vorangestellt werden.

Bereich lessen

Im folgenden Beispiel sollen die Umleitungen aus dem Bereich UrlMappings aufgelistet und in der Folge auch ergänzt werden. Für die Darstellung wird dazu lediglich ein GridView Control gewählt, dem die urlMappings-Auflistung übergeben wird.

In einer web.config gibt es mehrere Hauptbereiche, die mit dem Befehl GetSectionGroup referenziert werden können. Die UrlMappings befinden sich in System.Web. Da die Rückgabe gleich in einem Objekt vom Typ urlMappingsSection abgelegt wird, kann man die dort vorhandene Funktion Mappings verwenden, um die Liste für Gridview zu erhalten.

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
   Dim myconf As Configuration = WebConfigurationManager.OpenWebConfiguration("/ASPNET20CC")
   Dim myUrls As UrlMappingsSection
   Dim myGroup As System.Web.Configuration.SystemWebSectionGroup = myconf.GetSectionGroup("system.web")
   myUrls = myGroup.UrlMappings
   GridView1.DataSource = myUrls.UrlMappings
   GridView1.DataBind()
End Sub

Listing 5: Anzeige im Browser der urlMappings aus web.config

HINWEIS: Für weitere Konfigurationen wie z. B. an der machine.config, muss auf die Klassen des Namespace System.Config zugegriffen werden.

Die Anwendung erhält weiterhin zwei Textboxen, in die man neue URL-Umleitungen eintragen kann. ASP.NET erfordert immer eine Tilde »~«, die den Anwendungsstamm in der Eingabe darstellt.

urlMappings werden neu hinzugefügt
Abbildung 10: urlMappings werden neu hinzugefügt

Bereich speichern

Der nächste Schritt ist das Sichern der Änderungen. Auch dazu kommt wie vorher beschrieben der Web Configuration Manager zum Einsatz. Im vorherigen Bild kann man die Spalte LockItem erkennen, die Auskunft darüber gibt, ob jemand diese Daten zum Schreiben vorgesehen hat. Auch der Sperrmechanismus kommt aus der API.

Zunächst aber wird im folgenden Beispiel an die Auflistung der Mappings mit Hilfe des Add-Befehls ein neues Mapping erzeugt. Die Werte werden den Textboxen entnommen, die vom Benutzer eingegeben wurden.

Bevor der Schreibvorgang ausgeführt werden kann, wird geprüft, ob der Bereich sperrbar ist. Dann wird mit Save die Änderung zurück geschrieben.

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As System.EventArgs)
   Dim myconf As Configuration = WebConfigurationManager.OpenWebConfiguration("/ASPNET20CC")
   Dim myUrls As UrlMappingsSection
   Dim myGroup As System.Web.Configuration.SystemWebSectionGroup = myconf.GetSectionGroup("system.web")
   myUrls = myGroup.UrlMappings
   myUrls.UrlMappings.Add(New UrlMapping(txtUrl.Text, txtZiel.Text))
   If Not myUrls.LockItem Then
            myconf.Save()
   End If
End Sub

Listing 6: Speichern der Änderungen in web.config

Dies bietet natürlich nur einen kurzen Einblick in die Möglichkeiten der Configuration API.

Kompilierung

Mit ASP.NET 1.x wurden Webanwendungen in eine DLL kompiliert. Diese liegt dann im bin-Verzeichnis der Webanwendung. Beim ersten Aufruf einer ASPX-Seite springt dann der JIT-Compiler an und erstellt den eigentlichen Binärcode. Das Verfahren hatte seine Schwächen, speziell bei umfangreicheren Webseiten.

Da jetzt die eigentlichen Projektdateien wegfallen, muss auch keine große DLL erzeugt werden. Es gibt für jeden Bedarf die richtige Art, seine Webpräsenz zu kompilieren.

Automatische Kompilierung

Am einfachsten ist es, gar keine Vorgaben zu machen. Beim ersten Aufruf einer ASPX-Seite wird diese dann automatisch kompiliert. Beim nächsten Aufruf wird sie aus dem Cache geladen.

Pre Kompilierung

Aus verschiedenen Gründen kann es Sinn machen, Webseiten vorzukompilieren. Dabei können Fehler im Code schneller, eben zur Kompilierzeit, erkannt werden.

Ein gewichtigeres Argument ist aber sicher die Performance, da die Wartezeiten beim ersten Aufruf entfallen.

Am besten ist aber die neue Funktion, mit deren Hilfe Sie sogar ASPX-Seiten komplett in eine DLL kompilieren können. Dadurch muss man den HTML-Ausgangscode nicht mehr weitergeben.

Wenn Sie Visual Studio verwenden, lässt sich das über das Menü durchführen.

Mit dem Menüpunkt Build Solution - Build wird eine normale Kompilierung durchgeführt. Um eine Webseite für die Weitergabe zum Produktionsserver vorzubereiten, gibt es ebenfalls im Menü Build den Menüunterpunkt Publish. Damit wird das Projekt neu erstellt und gleich zum Produktionsserver kopiert.

Website kompilieren und weitergeben
Abbildung 11: Website kompilieren und weitergeben

Wenn die Option Allow this precompiled Site to be updateable deaktiviert ist, wird der HTML-Code aus den ASPX-Seiten entfernt und in die DLL einkompiliert.

Alle ASPX-Dateien sind dann leer und können nicht mehr vom Kunden oder Website-Betreiber verändert werden. Die DLL-Dateien liegen dann wie bisher im bin-Verzeichnis, pro Webseite und Klassendatei gibt es jeweils eine eigene Datei.

Das fertig erstellte Web-Projekt
Abbildung 12: Das fertig erstellte Web-Projekt

Kommandozeilenkompilierung

Wer lieber manuell vorgeht oder dies für Kommandozeilen-Operationen (z. B. bei der Batch-Verarbeitung) benötigt, kann den ASP.NET-Compilervorgang auch per Kommandozeile anstoßen. Das Kommando dafür lautet aspnet_compiler. Mit dem Parameter -V gefolgt vom Namen des virtuellen Verzeichnisses wird dieses kompiliert.

aspnet_compiler -v virtualPath

Weitere zusätzliche Parameter erlauben erweiterte Möglichkeiten.

Health Monitoring

Mit Health Monitoring wurde in ASP.NET 2.0 ein völliger neuer Mechanismus geschaffen, um Webanwendungen zu überwachen. Dank eines Provider-Konzeptes können die Nachrichten an verschiedene Systeme geschickt werden.

  • Windows Management Instrumentation (WMI)

  • Windows Ereignisanzeige

  • Windows Event Tracing

  • Performance Counter

  • SQL Databank logging

  • E-Mail

  • Log files

Das Verhalten der Provider lässt sich dabei per web.config konfigurieren.

HINWEIS: Um Health Monitoring auch nur in groben Zügen zu beschreiben, fehlt hier leider der Platz. Außerdem sind noch Änderungen bis zur Fertigstellung von Visual Studio 2005 zu erwarten.


Anzeigen: