Konfiguration und Instrumentierung

von Microsoft

In ASP.NET 2.0 gibt es wichtige Änderungen an der Konfiguration und Instrumentierung. Mit der neuen ASP.NET-Konfigurations-API können Konfigurationsänderungen programmgesteuert vorgenommen werden. Darüber hinaus sind viele neue Konfigurationseinstellungen vorhanden, die neue Konfigurationen und Instrumentierung ermöglichen.

In ASP.NET 2.0 gibt es wichtige Änderungen an der Konfiguration und Instrumentierung. Mit der neuen ASP.NET-Konfigurations-API können Konfigurationsänderungen programmgesteuert vorgenommen werden. Darüber hinaus sind viele neue Konfigurationseinstellungen vorhanden, die neue Konfigurationen und Instrumentierung ermöglichen.

In diesem Modul wird ASP.NET der Konfigurations-API im Zusammenhang mit dem Lesen und Schreiben von ASP.NET Konfigurationsdateien erläutert. Außerdem werden ASP.NET Instrumentierung behandelt. Wir werden auch die neuen Features behandeln, die in ASP.NET Ablaufverfolgung verfügbar sind.

ASP.NET-Konfigurations-API

Mit der ASP.NET-Konfigurations-API können Sie Anwendungskonfigurationsdaten mithilfe einer einzelnen Programmierschnittstelle entwickeln, bereitstellen und verwalten. Sie können die Konfigurations-API verwenden, um vollständige ASP.NET Konfigurationen programmgesteuert zu entwickeln und zu ändern, ohne die XML-Datei in den Konfigurationsdateien direkt zu bearbeiten. Darüber hinaus können Sie die Konfigurations-API in von Ihnen entwickelten Konsolenanwendungen und Skripts, in webbasierten Verwaltungstools und in MMC-Snap-Ins (Microsoft Management Console) verwenden.

Die folgenden beiden Konfigurationsverwaltungstools verwenden die Konfigurations-API und sind im .NET Framework Version 2.0 enthalten:

• Die ASP.NET MMC-Snap-Ins, das die Konfigurations-API verwendet, um administrative Aufgaben zu vereinfachen und eine integrierte Ansicht der lokalen Konfigurationsdaten auf allen Ebenen der Konfigurationshierarchie bereitzustellen.
• Das Websiteverwaltungstool, mit dem Sie Konfigurationseinstellungen für lokale und Remoteanwendungen verwalten können, einschließlich gehosteter Websites.

Die ASP.NET-Konfigurations-API umfasst eine Reihe von ASP.NET Verwaltungsobjekten, die Sie zum programmgesteuerten Konfigurieren von Websites und Anwendungen verwenden können. Verwaltungsobjekte werden als .NET Framework Klassenbibliothek implementiert. Das Programmiermodell der Konfigurations-API trägt dazu bei, Codekonsistenz und Zuverlässigkeit sicherzustellen, indem Datentypen zur Kompilierzeit erzwungen werden. Um die Verwaltung von Anwendungskonfigurationen zu vereinfachen, können Sie mit der Konfigurations-API Daten anzeigen, die von allen Punkten in der Konfigurationshierarchie als einzelne Sammlung zusammengeführt werden, anstatt die Daten als separate Sammlungen aus verschiedenen Konfigurationsdateien anzuzeigen. Darüber hinaus können Sie mit der Konfigurations-API ganze Anwendungskonfigurationen bearbeiten, ohne die XML-Datei in den Konfigurationsdateien direkt zu bearbeiten. Schließlich vereinfacht die API Konfigurationsaufgaben, indem sie Verwaltungstools unterstützt, z. B. das Websiteverwaltungstool. Die Konfigurations-API vereinfacht die Bereitstellung, indem sie die Erstellung von Konfigurationsdateien auf einem Computer unterstützt und Konfigurationsskripts auf mehreren Computern ausführt.

Arbeiten mit lokalen und Remotekonfigurationseinstellungen

Ein Configuration-Objekt stellt die zusammengeführte Ansicht der Konfigurationseinstellungen dar, die für eine bestimmte physische Entität gelten, z. B. einen Computer, oder für eine logische Entität, z. B. eine Anwendung oder eine Website. Die angegebene logische Entität kann auf dem lokalen Computer oder auf einem Remoteserver vorhanden sein. Wenn für eine angegebene Entität keine Konfigurationsdatei vorhanden ist, stellt das Configuration-Objekt die Standardkonfigurationseinstellungen dar, die durch die Machine.config-Datei definiert sind.

Sie können ein Configuration-Objekt abrufen, indem Sie eine der geöffneten Konfigurationsmethoden aus den folgenden Klassen verwenden:

1. Die ConfigurationManager-Klasse, wenn Ihre Entität eine Clientanwendung ist.
2. Die WebConfigurationManager-Klasse, wenn Ihre Entität eine Webanwendung ist.

Diese Methoden geben ein Configuration-Objekt zurück, das wiederum die erforderlichen Methoden und Eigenschaften für die Verarbeitung der zugrunde liegenden Konfigurationsdateien bereitstellt. Sie können auf diese Dateien zum Lesen oder Schreiben zugreifen.

Aktuell gelesen

Sie verwenden die GetSection- oder GetSectionGroup-Methode, um Konfigurationsinformationen zu lesen. Der Benutzer oder Prozess, der liest, muss über Leseberechtigungen für alle Konfigurationsdateien in der Hierarchie verfügen.

Schreiben

Sie verwenden eine der Save-Methoden, um Konfigurationsinformationen zu schreiben. Der Benutzer oder prozess, der schreibt, muss über Schreibberechtigungen für die Konfigurationsdatei und das Verzeichnis auf der aktuellen Konfigurationshierarchieebene sowie über Leseberechtigungen für alle Konfigurationsdateien in der Hierarchie verfügen.

Verwenden Sie eine der folgenden Speicherkonfigurationsmethoden, um eine Konfigurationsdatei zu generieren, die die geerbten Konfigurationseinstellungen für eine angegebene Entität darstellt:

1. Die Save-Methode zum Erstellen einer neuen Konfigurationsdatei.
2. Die SaveAs-Methode zum Generieren einer neuen Konfigurationsdatei an einem anderen Speicherort.

Konfigurationsklassen und Namespaces

Viele Konfigurationsklassen und Methoden sind einander ähnlich. In der folgenden Tabelle werden die am häufigsten verwendeten Konfigurationsklassen und Namespaces beschrieben.

Konfigurationsklasse oder -namespace	Beschreibung
System.Configuration-Namespace	Enthält die Standard-Konfigurationsklassen für alle .NET Framework-Anwendungen. Abschnittshandlerklassen werden verwendet, um Konfigurationsdaten für einen Abschnitt aus Methoden wie GetSection und GetSectionGroup abzurufen. Diese beiden Methoden sind nicht statisch.
System.Configuration.Configuration-Klasse	Stellt einen Satz von Konfigurationsdaten für einen Computer, eine Anwendung, ein Webverzeichnis oder eine andere Ressource dar. Diese Klasse enthält nützliche Methoden wie GetSection und GetSectionGroup, um Konfigurationseinstellungen zu aktualisieren und Verweise auf Abschnitte und Abschnittsgruppen abzurufen. Diese Klasse wird als Rückgabetyp für Methoden verwendet, die Entwurfszeitkonfigurationsdaten abrufen, z. B. die Methoden der Klassen WebConfigurationManager und ConfigurationManager.
System.Web.Configuration-Namespace	Enthält die Abschnittshandlerklassen für die ASP.NET Konfigurationsabschnitte, die unter ASP.NET Konfigurationseinstellungen definiert sind. Abschnittshandlerklassen werden verwendet, um Konfigurationsdaten für einen Abschnitt aus Methoden wie GetSection und GetSectionGroup abzurufen.
System.Web.Configuration.WebConfigurationManager-Klasse	Stellt nützliche Methoden zum Abrufen von Verweisen auf Laufzeit- und Entwurfszeitkonfigurationseinstellungen bereit. Diese Methoden verwenden die System.Configuration.Configuration-Klasse als Rückgabetyp. Sie können die statische GetSection-Methode dieser Klasse oder die nicht statische GetSection-Methode der System.Configuration.ConfigurationManager-Klasse austauschbar verwenden. Für Webanwendungskonfigurationen wird die System.Web.Configuration.WebConfigurationManager-Klasse anstelle der System.Configuration.ConfigurationManager-Klasse empfohlen.
System.Configuration.Provider-Namespace	Bietet eine Möglichkeit zum Anpassen und Erweitern des Konfigurationsanbieters. Dies ist die Basisklasse für alle Anbieterklassen im Konfigurationssystem.
System.Web.Management-Namespace	Dieser Namespace enthält Klassen und Schnittstellen zum Verwalten und Überwachen der Integrität von Webanwendungen. Genau genommen wird dieser Namespace nicht als Teil der Konfigurations-API betrachtet. Beispielsweise erfolgt die Ablaufverfolgung und das Auslösen von Ereignissen durch die Klassen in diesem Namespace.
System.Management.Instrumentation-Namespace	Stellt die Klassen bereit, die für die Instrumentierung von Anwendungen erforderlich sind, um ihre Verwaltungsinformationen und Ereignisse über die Windows-Verwaltungsinstrumentation (WMI) für potenzielle Consumer verfügbar zu machen. ASP.NET Integritätsüberwachung verwendet WMI zum Übermitteln von Ereignissen. Genau genommen wird dieser Namespace nicht als Teil der Konfigurations-API betrachtet.

Lesen aus ASP.NET-Konfigurationsdateien

Die WebConfigurationManager-Klasse ist die Kernklasse zum Lesen aus ASP.NET Konfigurationsdateien. Es gibt im Wesentlichen drei Schritte zum Lesen ASP.NET Konfigurationsdateien:

1. Rufen Sie mithilfe der OpenWebConfiguration-Methode ein Configuration-Objekt ab.
2. Rufen Sie einen Verweis auf den gewünschten Abschnitt in der Konfigurationsdatei ab.
3. Lesen Sie die gewünschten Informationen aus der Konfigurationsdatei.

Das Configuration-Objekt stellt keine bestimmte Konfigurationsdatei dar. Stattdessen stellt sie eine zusammengeführte Ansicht der Konfiguration eines Computers, einer Anwendung oder einer Website dar. Im folgenden Codebeispiel wird ein Configuration-Objekt instanziiert, das die Konfiguration einer Webanwendung mit dem Namen ProductInfo darstellt.

Configuration config = WebConfigurationManager.OpenWebConfiguration("/ProductInfo);

Sobald Sie über das Configuration-Objekt verfügen, können Sie die GetSection- oder GetSectionGroup-Methode verwenden, um einen Drilldown in die Konfigurationseinstellungen zu erhalten. Im folgenden Beispiel wird ein Verweis auf die Identitätswechseleinstellungen für die obige ProductInfo-Anwendung abgerufen:

Configuration config =
    WebConfigurationManager.OpenWebConfiguration("/ProductInfo);
IdentitySection section =
   (IdentitySection)config.GetSection("system.web/identity");

Schreiben in ASP.NET Konfigurationsdateien

Wie beim Lesen aus Konfigurationsdateien ist die WebConfigurationManager-Klasse der Kern für das Schreiben in Asp.NET Konfigurationsdateien. Es gibt auch drei Schritte zum Schreiben in ASP.NET Konfigurationsdateien.

1. Rufen Sie mithilfe der OpenWebConfiguration-Methode ein Configuration-Objekt ab.
2. Rufen Sie einen Verweis auf den gewünschten Abschnitt in der Konfigurationsdatei ab.
3. Schreiben Sie die gewünschten Informationen aus der Konfigurationsdatei mithilfe der Save- oder SaveAs-Methode.

Mit dem folgenden Code wird das Debug-Attribut des <Kompilierungselements> in false geändert:

System.Configuration.Configuration updateWebConfig =
    System.Web.Configuration.WebConfigurationManager.OpenWebConfiguration("/webApp");

System.Web.Configuration.CompilationSection compilation =
    updateWebConfig.GetSection("system.web/compilation")
    as System.Web.Configuration.CompilationSection;

compilation.Debug = false;

if (!compilation.SectionInformation.IsLocked) {
    updateWebConfig.Save();
    Response.Write("Save Success!");
} else {
    Response.Write("Save Failed!");
}

Wenn dieser Code ausgeführt wird, wird das debug-Attribut des <Kompilierungselements> für die web.config Datei der WebApp-Anwendung auf false festgelegt.

System.Web.Management-Namespace

Der System.Web.Management-Namespace stellt die Klassen und Schnittstellen zum Verwalten und Überwachen der Integrität von ASP.NET Anwendungen bereit.

Die Protokollierung erfolgt durch Definieren einer Regel, die Ereignisse einem Anbieter zuordnet. Die Regel definiert den Typ von Ereignissen, die an den Anbieter gesendet werden. Die folgenden Basisereignisse stehen ihnen zum Protokollieren zur Verfügung:

Webbaseevent	Die Basisereignisklasse für alle Ereignisse. Enthält die erforderlichen Eigenschaften für alle Ereignisse, z. B. Ereigniscode, Ereignisdetails, Datum und Uhrzeit des Auslösens des Ereignisses, Sequenznummer, Ereignismeldung und Ereignisdetails.
Webmanagementevent	Die Basisereignisklasse für Verwaltungsereignisse, z. B. Anwendungslebensdauer, Anforderung, Fehler und Überwachungsereignisse.
WebHeartbeatEvent	Das von der Anwendung in regelmäßigen Abständen generierte Ereignis, um nützliche Laufzeitzustandsinformationen zu erfassen.
Webauditevent	Die Basisklasse für Sicherheitsüberwachungsereignisse, die verwendet werden, um Bedingungen wie Autorisierungsfehler, Entschlüsselungsfehler usw. zu markieren.
Webrequestevent	Die Basisklasse für alle Informationsanforderungsereignisse.
Webbaseerrorevent	Die Basisklasse für alle Ereignisse, die Fehlerbedingungen angeben.

Mit den verfügbaren Anbietertypen können Sie ereignisausgabe an Ereignisanzeige, SQL Server, Windows-Verwaltungsinstrumentation (WMI) und E-Mails senden. Die vorkonfigurierten Anbieter und Ereigniszuordnungen reduzieren den Aufwand, der zum Protokollieren der Ereignisausgabe erforderlich ist.

ASP.NET 2.0 verwendet standardmäßig den Ereignisprotokollanbieter, um Ereignisse basierend auf dem Starten und Beenden von Anwendungsdomänen zu protokollieren und alle nicht behandelten Ausnahmen zu protokollieren. Dies hilft, einige der grundlegenden Szenarien abzudecken. Angenommen, Ihre Anwendung löst eine Ausnahme aus, aber der Benutzer speichert den Fehler nicht, und Sie können ihn nicht reproduzieren. Mit der Standardereignisprotokollregel könnten Sie die Ausnahme- und Stapelinformationen sammeln, um eine bessere Vorstellung davon zu erhalten, welche Art von Fehler aufgetreten ist. Ein weiteres Beispiel gilt, wenn ihre Anwendung den Sitzungszustand verliert. In diesem Fall können Sie im Ereignisprotokoll nachsehen, ob die Anwendungsdomäne wiederverwendet wird und warum die Anwendungsdomäne überhaupt beendet wurde.

Außerdem ist das System zur Integritätsüberwachung erweiterbar. Beispielsweise können Sie benutzerdefinierte Webereignisse definieren, sie innerhalb Ihrer Anwendung auslösen und dann eine Regel zum Senden der Ereignisinformationen an einen Anbieter wie Ihre E-Mail definieren. Auf diese Weise können Sie Ihre Instrumentierung ganz einfach an die Anbieter der Integritätsüberwachung binden. Ein weiteres Beispiel: Sie können jedes Mal, wenn eine Bestellung verarbeitet wird, ein Ereignis auslösen und eine Regel einrichten, die jedes Ereignis an die SQL Server-Datenbank sendet. Sie können auch ein Ereignis auslösen, wenn sich ein Benutzer nicht mehrmals hintereinander anmeldet, und das Ereignis für die Verwendung der E-Mail-basierten Anbieter einrichten.

Die Konfiguration für die Standardanbieter und -ereignisse wird in der globalen Web.config-Datei gespeichert. Die datei "Global Web.config" speichert alle webbasierten Einstellungen, die in der Machine.config-Datei in ASP.NET 1x gespeichert wurden. Die datei "Global Web.config" befindet sich im folgenden Verzeichnis:

%windir%\Microsoft.Net\Framework\v2.0.*\config\Web.config

Der <Abschnitt healthMonitoring> der Datei "Global Web.config" enthält Standardkonfigurationseinstellungen. Sie können diese Einstellung überschreiben oder Eigene Einstellungen konfigurieren, indem Sie den <Abschnitt healthMonitoring> in der Web.config-Datei für Ihre Anwendung implementieren.

Der <Abschnitt healthMonitoring> der datei "Global Web.config" enthält die folgenden Elemente:

providers	Enthält Anbieter, die für die Ereignisanzeige, WMI und SQL Server eingerichtet sind.
Eventmappings	Enthält Zuordnungen für die verschiedenen WebBase-Klassen. Sie können diese Liste erweitern, wenn Sie Eine eigene Ereignisklasse generieren. Durch das Generieren einer eigenen Ereignisklasse erhalten Sie eine präzisere Granularität gegenüber den Anbietern, an die Sie Informationen senden. Sie können beispielsweise nicht behandelte Ausnahmen so konfigurieren, dass sie an SQL Server gesendet werden, während Sie Ihre eigenen benutzerdefinierten Ereignisse an E-Mail senden.
Regeln	Verknüpft die eventMappings mit dem Anbieter.
Pufferung	Wird mit SQL Server- und E-Mail-Anbietern verwendet, um zu bestimmen, wie oft die Ereignisse an den Anbieter geleert werden sollen.

Im Folgenden finden Sie ein Codebeispiel aus der globalen Web.config-Datei.

<healthMonitoring>
  <!-- Event Log Provider being added. -->
  <providers>
    <add name="EventLogProvider"
         type="System.Web.Management.EventLogWebEventProvider,
               System.Web,Version=2.0.0.0,Culture=neutral,
               PublicKeyToken=b03f5f7f11d50a3a" />
  </providers>
  <!-- Event mapping provides a friendly name to the
events based on the WebBaseErrorEvent class. -->
  <eventMappings>
    <add name="All Errors"
         type="System.Web.Management.WebBaseErrorEvent,
               System.Web,Version=2.0.0.0,Culture=neutral,
               PublicKeyToken=b03f5f7f11d50a3a"
          startEventCode="0" endEventCode="2147483647" />
  </eventMappings>
  <!-- Rule tying the "All Errors" event mapping to the EventLog Provider. -->
  <rules>
    <add name="All Errors Default" eventName="All Errors"
         provider="EventLogProvider"
         profile="Default" minInstances="1"
         maxLimit="Infinite" minInterval="00:01:00" custom="" />
  </rules>
</healthMonitoring>

Speichern von Ereignissen in Ereignisanzeige

Wie bereits erwähnt, ist der Anbieter für die Protokollierung von Ereignissen im Ereignisanzeige für Sie in der datei globalen Web.config konfiguriert. Standardmäßig werden alle Ereignisse protokolliert, die auf WebBaseErrorEvent und WebFailureAuditEvent basieren. Sie können zusätzliche Regeln hinzufügen, um zusätzliche Informationen im Ereignisprotokoll zu protokollieren. Wenn Sie beispielsweise alle Ereignisse (d. h. jedes Ereignis basierend auf WebBaseEvent) protokollieren möchten, können Sie der Web.config-Datei die folgende Regel hinzufügen:

<healthMonitoring>
    <rules>
        <add name="All Events" eventName="All Events"
             provider="EventLogProvider" profile="Critical" />
    </rules>
</healthMonitoring>

Diese Regel würde die Ereigniszuordnung Alle Ereignisse mit dem Ereignisprotokollanbieter verknüpfen. Sowohl eventMapping als auch der Anbieter sind in der datei globalen Web.config enthalten.

Speichern von Ereignissen in SQL Server

Diese Methode verwendet die ASPNETDB-Datenbank , die vom Aspnet_regsql.exe-Tool generiert wird. Der Standardanbieter verwendet die LocalSqlServer-Verbindungszeichenfolge, die entweder eine dateibasierte Datenbank im Ordner App_data oder die lokale SQLExpress-instance von SQL Server verwendet. Sowohl die LocalSqlServer-Verbindungszeichenfolge als auch der SqlProvider sind in der globalen Web.config-Datei konfiguriert.

Die LocalSqlServer-Verbindungszeichenfolge in der globalen Web.config-Datei sieht wie folgt aus:

<connectionStrings>
    <add name="LocalSqlServer"
         connectionString="data source=.\SQLEXPRESS;
         Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;
         User Instance=true"
         providerName="System.Data.SqlClient" />
</connectionStrings>

Wenn Sie eine andere SQL Server instance verwenden möchten, müssen Sie das tool Aspnet_regsql.exe verwenden, das sich im Ordner %windir%\Microsoft.Net\Framework\v2.0.* befindet. Verwenden Sie das Aspnet_regsql.exe-Tool, um eine benutzerdefinierte ASPNETDB-Datenbank auf der SQL Server instance zu generieren, fügen Sie dann die Verbindungszeichenfolge zur Konfigurationsdatei Ihrer Anwendung hinzu, und fügen Sie dann mithilfe der neuen Verbindungszeichenfolge einen Anbieter hinzu. Nachdem Sie die ASPNETDB-Datenbank erstellt haben, müssen Sie eine Regel festlegen, um eine eventMapping-Instanz mit dem sqlProvider zu verknüpfen.

Unabhängig davon, ob Sie den Standard-SqlProvider verwenden oder Ihren eigenen Anbieter konfigurieren, müssen Sie eine Regel hinzufügen, die den Anbieter mit einer Ereigniszuordnung verknüpft. Die folgende Regel verknüpft den neuen Anbieter, den Sie oben erstellt haben, mit der Ereigniszuordnung Alle Ereignisse . Diese Regel protokolliert alle Ereignisse basierend auf WebBaseEvent und sendet sie an den MySqlWebEventProvider, der die MYASPNETDB-Verbindungszeichenfolge verwendet. Der folgende Code fügt eine Regel hinzu, um den Anbieter mit einer Ereigniszuordnung zu verknüpfen:

<healthMonitoring>
    <rules>
        <add name="All Events" eventName="All Events"
        provider="MySqlWebEventProvider" profile="Critical"/>
    </rules>
</healthMonitoring>

Wenn Sie nur Fehler an SQL Server senden möchten, können Sie die folgende Regel hinzufügen:

<add name="All Errors"
    eventName="All Errors"
    provider="MySqlWebEventProvider"
    profile="Critical"/>

Weiterleiten von Ereignissen an WMI

Sie können die Ereignisse auch an WMI weiterleiten. Der WMI-Anbieter ist standardmäßig für Sie in der datei globalen Web.config konfiguriert.

Im folgenden Codebeispiel wird eine Regel hinzugefügt, um die Ereignisse an WMI weiterzuleiten:

<providers>
    <add name="WmiWebEventProvider"
      type="System.Web.Management.WmiWebEventProvider,System.Web,
         Version=2.0.0.0,Culture=neutral,
         PublicKeyToken=b03f5f7f11d50a3a" />
</providers>

Sie müssen eine Regel hinzufügen, um dem Anbieter ein eventMapping zuzuordnen, sowie eine WMI-Listeneranwendung zum Lauschen auf die Ereignisse. Im folgenden Codebeispiel wird eine Regel hinzugefügt, um den WMI-Anbieter mit der Ereigniszuordnung "Alle Ereignisse" zu verknüpfen:

<rules>
    <add name="All Events"
      eventName="All Events" provider="WmiWebEventProvider"
        profile="Critical" />
</rules>

Weiterleiten von Ereignissen an E-Mails

Sie können Ereignisse auch an E-Mails weiterleiten. Achten Sie darauf, welche Ereignisregeln Sie Ihrem E-Mail-Anbieter zuordnen, da Sie sich unbeabsichtigt viele Informationen senden können, die für SQL Server oder das Ereignisprotokoll besser geeignet sind. Es gibt zwei E-Mail-Anbieter; SimpleMailWebEventProvider und TemplatedMailWebEventProvider. Jedes verfügt über die gleichen Konfigurationsattribute, mit Ausnahme der Attribute "template" und "detailedTemplateErrors", die beide nur im TemplatedMailWebEventProvider verfügbar sind.

Der Standard Unterschied zwischen diesen beiden E-Mail-Anbietern besteht darin, dass SimpleMailWebEventProvider E-Mails in einer generischen Vorlage sendet, die nicht geändert werden kann. Die Beispieldatei Web.config fügt diesen E-Mail-Anbieter der Liste der konfigurierten Anbieter mithilfe der folgenden Regel hinzu:

<add name="mySimple-mailWebEventProvider"
     type="System.Web.Management.Simple-mailWebEventProvider"
     to="e-mail@foo.com" from="e-mail@foo.com"
     maxMessagesPerNotification="1" maxEventsPerMessage="10"
     buffer="true" bufferMode="Critical Notification"
     subjectPrefix="Web Events"/>

Die folgende Regel wird auch hinzugefügt, um den E-Mail-Anbieter an die Ereigniszuordnung "Alle Ereignisse" zu binden:

<add name="All Events" eventName="All Events"
    provider="mySimple-mailWebEventProvider" profile="Critical"/>

Ablaufverfolgung von ASP.NET 2.0

In ASP.NET 2.0 gibt es drei wesentliche Verbesserungen bei der Ablaufverfolgung.

1. Integrierte Ablaufverfolgungsfunktionalität
2. Programmgesteuerter Zugriff auf Ablaufverfolgungsnachrichten
3. Verbesserte Ablaufverfolgung auf Anwendungsebene

Integrierte Ablaufverfolgungsfunktionalität

Sie können jetzt von der System.Diagnostics.Trace-Klasse ausgegebene Nachrichten an ASP.NET Ablaufverfolgungsausgabe weiterleiten und von ASP.NET Ablaufverfolgung ausgegebene Nachrichten an System.Diagnostics.Trace weiterleiten. Sie können auch ASP.NET Instrumentierungsereignisse an System.Diagnostics.Trace weiterleiten. Diese Funktionalität wird durch das neue writeToDiagnosticsTrace-Attribut des <Ablaufverfolgungselements> bereitgestellt. Wenn dieser boolesche Wert true ist, werden ASP.NET Ablaufverfolgungsmeldungen an die System.Diagnostics-Ablaufverfolgungsinfrastruktur weitergeleitet, um sie von allen Listenern zu verwenden, die zum Anzeigen von Ablaufverfolgungsmeldungen registriert sind.

Programmgesteuerter Zugriff auf Ablaufverfolgungsnachrichten

ASP.NET 2.0 ermöglicht den programmgesteuerten Zugriff auf alle Ablaufverfolgungsnachrichten über die TraceContextRecord-Klasse und die TraceRecords-Auflistung . Der effizienteste Zugriff auf Ablaufverfolgungsmeldungen besteht darin, einen TraceContextEventHandler-Delegat (ebenfalls neu in ASP.NET 2.0) zu registrieren, um das neue TraceFinished-Ereignis zu behandeln. Anschließend können Sie die Ablaufverfolgungsmeldungen nach Belieben durchlaufen.

Das folgende Codebeispiel veranschaulicht folgendes:

void Page_Load(object sender, EventArgs e) {
    // Register a handler for the TraceFinished event.
    Trace.TraceFinished += new
        TraceContextEventHandler(this.OnTraceFinished);
    // Write a trace message.
    Trace.Write("Web Forms Infrastructure Methods", 
      "USERMESSAGE: Page_Load complete.");
}

// A TraceContextEventHandler for the TraceFinished event.
void OnTraceFinished(object sender, TraceContextEventArgs e) {
    TraceContextRecord r = null;
    // Iterate through the collection of trace records and write
    // them to the response stream.
    foreach (object o in e.TraceRecords) {
        r = (TraceContextRecord)o;
        Response.Write(String.Format("trace message: {0} <BR>",
        r.Message));
    }
}

Im obigen Beispiel durchläuft ich die TraceRecords-Auflistung und schreibe dann jede Nachricht in den Antwortstream.

Verbesserte Application-Level Ablaufverfolgung

Die Ablaufverfolgung auf Anwendungsebene wird durch die Einführung des neuen mostRecent-Attributs des <Ablaufverfolgungselements> verbessert. Dieses Attribut gibt an, ob die neueste Ablaufverfolgungsausgabe auf Anwendungsebene angezeigt wird und ältere Ablaufverfolgungsdaten, die über die grenzwerte hinausgehen, die durch das requestLimit angegeben werden, verworfen werden. Wenn false, werden Ablaufverfolgungsdaten für Anforderungen angezeigt, bis das attribut requestLimit erreicht ist.

ASP.NET Befehlszeilentools

Es gibt mehrere Befehlszeilentools, die die Konfiguration von ASP.NET unterstützen. ASP.NET Entwickler sollten mit dem aspnet_regiis.exe-Tool vertraut sein. ASP.NET 2.0 stellt drei weitere Befehlszeilentools bereit, um die Konfiguration zu unterstützen.

Die folgenden Befehlszeilentools sind verfügbar:

Tool	Verwenden Sie
aspnet_regiis.exe	Ermöglicht die Registrierung von ASP.NET mit IIS. Es gibt zwei Versionen dieser Tools, die mit ASP.NET 2.0 ausgeliefert werden: eine für 32-Bit-Systeme (im Ordner Framework) und eine für 64-Bit-Systeme (im Ordner Framework64).) Die 64-Bit-Version wird unter einem 32-Bit-Betriebssystem nicht installiert.
aspnet_regsql.exe	Das ASP.NET SQL Server Registrierungstool wird verwendet, um eine Microsoft SQL Server-Datenbank für die Verwendung durch die SQL Server-Anbieter in ASP.NET zu erstellen oder Um Optionen aus einer vorhandenen Datenbank hinzuzufügen oder zu entfernen. Die Aspnet_regsql.exe Datei befindet sich im Ordner [laufwerk:]\WINDOWS\Microsoft.NET\Framework\versionNumber auf Ihrem Webserver.
aspnet_regbrowsers.exe	Das ASP.NET Browserregistrierungstool analysiert und kompiliert alle systemweiten Browserdefinitionen in einer Assembly und installiert die Assembly im globalen Assemblycache. Das Tool verwendet die Browserdefinitionsdateien (. BROWSER-Dateien) aus dem Unterverzeichnis .NET Framework Browser. Das Tool finden Sie im Verzeichnis %SystemRoot%\Microsoft.NET\Framework\version\.
aspnet_compiler.exe	Mit dem ASP.NET Kompilierungstool können Sie eine ASP.NET Webanwendung entweder an Ort oder für die Bereitstellung an einem Zielstandort wie einem Produktionsserver kompilieren. Die direkte Kompilierung unterstützt die Anwendungsleistung, da Endbenutzer keine Verzögerung bei der ersten Anforderung an die Anwendung feststellen, während die Anwendung kompiliert wird.

Da das aspnet_regiis.exe-Tool in ASP.NET 2.0 nicht neu ist, werden wir es hier nicht besprechen.

ASP.NET SQL Server Registrierungstool – aspnet_regsql.exe

Sie können mehrere Arten von Optionen mit dem ASP.NET SQL Server Registrierungstool festlegen. Sie können eine SQL-Verbindung angeben, angeben, welche ASP.NET-Anwendungsdienste SQL Server verwenden, um Informationen zu verwalten, welche Datenbank oder Tabelle für die SQL-Cacheabhängigkeit verwendet wird, und Unterstützung für die Verwendung SQL Server zum Speichern von Prozeduren und Sitzungsstatus hinzufügen oder entfernen.

Mehrere ASP.NET Anwendungsdienste sind von einem Anbieter abhängig, um das Speichern und Abrufen von Daten aus einer Datenquelle zu verwalten. Jeder Anbieter ist spezifisch für die Datenquelle. ASP.NET enthält einen SQL Server Anbieter für die folgenden ASP.NET Features:

• Membership (die SqlMembershipProvider-Klasse ).
• Rollenverwaltung (die SqlRoleProvider-Klasse ).
• Profile (die SqlProfileProvider-Klasse ).
• Personalisierung von Webparts (die SqlPersonalizationProvider-Klasse ).
• Webereignisse (die SqlWebEventProvider-Klasse ).

Wenn Sie ASP.NET installieren, enthält die Machine.config-Datei für Ihren Server Konfigurationselemente, die SQL Server Anbieter für jedes der ASP.NET Features angeben, die von einem Anbieter abhängig sind. Diese Anbieter sind standardmäßig für eine Verbindung mit einem lokalen Benutzer instance SQL Server Express 2005 konfiguriert. Wenn Sie die von den Anbietern verwendete Standardverbindungszeichenfolge ändern, müssen Sie die SQL Server Datenbank und die Datenbankelemente für das ausgewählte Feature mithilfe von Aspnet_regsql.exe installieren, bevor Sie eines der in der Computerkonfiguration konfigurierten ASP.NET Features verwenden können. Wenn die Datenbank, die Sie mit dem SQL-Registrierungstool angeben, noch nicht vorhanden ist (aspnetdb ist die Standarddatenbank, wenn sie nicht in der Befehlszeile angegeben ist), muss der aktuelle Benutzer über die Rechte zum Erstellen von Datenbanken in SQL Server sowie zum Erstellen von Schemaelementen in einer Datenbank verfügen.

SQL-Cacheabhängigkeit

Ein erweitertes Feature ASP.NET Ausgabezwischenspeicherung ist die SQL-Cacheabhängigkeit. Sql-Cacheabhängigkeit unterstützt zwei verschiedene Betriebsmodi: einen, der eine ASP.NET Implementierung von Tabellenabfragen verwendet, und einen zweiten Modus, der die Abfragebenachrichtigungsfeatures von SQL Server 2005 verwendet. Das SQL-Registrierungstool kann verwendet werden, um den Vorgangsmodus für die Tabellenabfrage zu konfigurieren.

Sitzungszustand

Standardmäßig werden Sitzungsstatuswerte und -informationen im Arbeitsspeicher innerhalb des ASP.NET-Prozesses gespeichert. Alternativ können Sie Sitzungsdaten in einer SQL Server Datenbank speichern, in der sie von mehreren Webservern freigegeben werden können. Wenn die Datenbank, die Sie für den Sitzungsstatus mit dem SQL-Registrierungstool angeben, noch nicht vorhanden ist, muss der aktuelle Benutzer über Die Rechte zum Erstellen von Datenbanken in SQL Server sowie zum Erstellen von Schemaelementen in einer Datenbank verfügen. Wenn die Datenbank vorhanden ist, muss der aktuelle Benutzer über Die Rechte zum Erstellen von Schemaelementen in der vorhandenen Datenbank verfügen.

Um die Sitzungsstatusdatenbank auf SQL Server zu installieren, führen Sie das Aspnet_regsql.exe-Tool aus, und geben Sie die folgenden Informationen mit dem Befehl an:

• Der Name des SQL Server instance mithilfe der Option -S.
• Die Anmeldeinformationen für ein Konto, das über die Berechtigung zum Erstellen einer Datenbank auf einem Computer verfügt, auf dem SQL Server ausgeführt wird. Verwenden Sie die Option -E , um den aktuell angemeldeten Benutzer zu verwenden, oder verwenden Sie die Option -U , um eine Benutzer-ID zusammen mit der Option -P anzugeben, um ein Kennwort anzugeben.
• Die Befehlszeilenoption -ssadd zum Hinzufügen der Sitzungsstatusdatenbank.

Standardmäßig können Sie das Tool Aspnet_regsql.exe nicht verwenden, um die Sitzungsstatusdatenbank auf einem Computer zu installieren, auf dem SQL Server 2005 Express Edition ausgeführt wird.

Das ASP.NET-Browserregistrierungstool – aspnet_regbrowsers.exe

In ASP.NET Version 1.1 enthielt die Machine.config-Datei einen Abschnitt namens <browserCaps>. Dieser Abschnitt enthielt eine Reihe von XML-Einträgen, die die Konfigurationen für verschiedene Browser basierend auf einem regulären Ausdruck definierten. Für ASP.NET Version 2.0 ist ein neuer . Die BROWSER-Datei definiert die Parameter eines bestimmten Browsers mithilfe von XML-Einträgen. Sie fügen Informationen zu einem neuen Browser hinzu, indem Sie einen neuen hinzufügen. BROWSER-Datei in den Ordner %SystemRoot%\Microsoft.NET\Framework\version\CONFIG\Browsers auf Ihrem System.

Da eine Anwendung keine .config-Datei jedes Mal liest, wenn sie Browserinformationen benötigt, können Sie eine neue erstellen. Browserdatei, und führen Sie Aspnet_regbrowsers.exe aus, um die erforderlichen Änderungen zur Assembly hinzuzufügen. Dadurch kann der Server sofort auf die neuen Browserinformationen zugreifen, sodass Sie keine Ihrer Anwendungen herunterfahren müssen, um die Informationen zu erfassen. Eine Anwendung kann über die Browsereigenschaft der aktuellen HttpRequest-Eigenschaft auf Browserfunktionen zugreifen.

Die folgenden Optionen sind verfügbar, wenn Sie aspnet_regbrowser.exe ausführen:

Option	Beschreibung
-?	Zeigt den Aspnet_regbbrowsers.exe Hilfetext im Befehlsfenster an.
-i	Erstellt die Laufzeitbrowserfunktionenassembly und installiert sie im globalen Assemblycache.
-u	Deinstalliert die Laufzeitbrowserfunktionenassembly aus dem globalen Assemblycache.

Das ASP.NET Kompilierungstool – aspnet_compiler.exe

Das ASP.NET Kompilierungstool kann auf zwei allgemeine Arten verwendet werden: für die direkte Kompilierung und kompilieren für die Bereitstellung, bei der ein Zielausgabeverzeichnis angegeben wird.

Erstellen einer Anwendung an Ort

Das ASP.NET Kompilierungstool kann eine Anwendung an Ort und Stelle kompilieren, d. h. es imitiert das Verhalten, mehrere Anforderungen an die Anwendung zu stellen, was zu einer regelmäßigen Kompilierung führt. Für Benutzer einer vorkompilierten Website tritt keine Verzögerung auf, die durch das Kompilieren der Seite bei der ersten Anforderung verursacht wird.

Wenn Sie eine Website vorkompilieren, gelten die folgenden Elemente:

• Die Website behält ihre Dateien und Verzeichnisstruktur bei.
• Sie benötigen Compiler für alle Programmiersprachen, die von der Website auf dem Server verwendet werden.
• Wenn bei einer Datei die Kompilierung fehlschlägt, schlägt die kompilierung der gesamten Website fehl.

Sie können eine Anwendung auch neu kompilieren, nachdem Sie ihr neue Quelldateien hinzugefügt haben. Das Tool kompiliert nur die neuen oder geänderten Dateien, es sei denn, Sie schließen die Option -c ein.

Kompilieren einer Anwendung für die Bereitstellung

Sie kompilieren eine Anwendung für die Bereitstellung (Kompilierung an einem Zielspeicherort), indem Sie den targetDir-Parameter angeben. TargetDir kann der endgültige Speicherort für die Webanwendung sein, oder die kompilierte Anwendung kann weiter bereitgestellt werden. Wenn Sie die - u-Option verwenden, wird die Anwendung so kompiliert, dass Sie Änderungen an bestimmten Dateien in der kompilierten Anwendung vornehmen können, ohne sie neu zu kompilieren. Aspnet_compiler.exe unterscheidet zwischen statischen und dynamischen Dateitypen und behandelt diese beim Erstellen der resultierenden Anwendung unterschiedlich.

• Statische Dateitypen sind solche, die keinen zugeordneten Compiler oder Buildanbieter aufweisen, z. B. Dateien, deren Namen Erweiterungen wie CSS, .gif, .htm, .html, .jpg, .js usw. aufweisen. Diese Dateien werden einfach an den Zielspeicherort kopiert, wobei ihre relativen Stellen in der Verzeichnisstruktur beibehalten werden.
• Dynamische Dateitypen sind solche, die über einen zugeordneten Compiler oder Buildanbieter verfügen, einschließlich Dateien mit ASP.NET spezifischen Dateinamenerweiterungen wie .asax, .ascx, .ashx, .aspx, .browser, . master usw. Das ASP.NET Kompilierungstool generiert Assemblys aus diesen Dateien. Wenn die Option -u ausgelassen wird, erstellt das Tool auch Dateien mit der Dateinamenerweiterung . COMPILED, das die ursprünglichen Quelldateien ihrer Assembly zuordnen. Um sicherzustellen, dass die Verzeichnisstruktur der Anwendungsquelle erhalten bleibt, generiert das Tool Platzhalterdateien an den entsprechenden Speicherorten in der Zielanwendung.

Sie müssen die Option -u verwenden, um anzugeben, dass der Inhalt der kompilierten Anwendung geändert werden kann. Andernfalls werden nachfolgende Änderungen ignoriert oder führen zu Laufzeitfehlern.

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

Dateityp	Compileraktion
.ascx, .aspx, . master	Diese Dateien sind in Markup- und Quellcode unterteilt, die sowohl CodeBehind-Dateien als auch Code enthalten, der in <skript runat="server"> -Elemente eingeschlossen ist. Quellcode wird in Assemblys mit Namen kompiliert, die von einem Hashalgorithmus abgeleitet sind, und die Assemblys werden im Verzeichnis Bin platziert. Jeder Inlinecode, d. h. Code, der zwischen den < Klammern % und %> eingeschlossen ist, ist im Markup enthalten und nicht kompiliert. Neue Dateien mit demselben Namen wie die Quelldateien werden erstellt, um das Markup zu enthalten, und in den entsprechenden Ausgabeverzeichnissen platziert.
.ashx, .asmx	Diese Dateien werden nicht kompiliert und unverändert in die Ausgabeverzeichnisse verschoben und nicht kompiliert. Wenn Sie den Handlercode kompilieren möchten, platzieren Sie den Code in Quellcodedateien im Verzeichnis App_Code.
CS, VB, JSL, CPP (ohne CodeBehind-Dateien für die zuvor aufgeführten Dateitypen)	Diese Dateien werden kompiliert und als Ressource in Assemblys eingeschlossen, die auf sie verweisen. Quelldateien werden nicht in das Ausgabeverzeichnis kopiert. Wenn nicht auf eine Codedatei verwiesen wird, wird sie nicht kompiliert.
Benutzerdefinierte Dateitypen	Diese Dateien werden nicht kompiliert. Diese Dateien werden in die entsprechenden Ausgabeverzeichnisse kopiert.
Quellcodedateien im unterverzeichnis App_Code	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt.
RESX- und RESSOURCENDATEIEN im Unterverzeichnis App_GlobalResources	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Unter dem Standard Ausgabeverzeichnis wird kein App_GlobalResources Unterverzeichnis erstellt, und es werden keine RESX- oder RESOURCES-Dateien im Quellverzeichnis in die Ausgabeverzeichnisse kopiert.
RESX- und RESSOURCENDATEIEN im Unterverzeichnis App_LocalResources	Diese Dateien werden nicht kompiliert und in die entsprechenden Ausgabeverzeichnisse kopiert.
SKIN-Dateien im unterverzeichnis App_Themes	Die SKIN-Dateien und statischen Designdateien werden nicht kompiliert und in die entsprechenden Ausgabeverzeichnisse kopiert.
Browser Web.config Statische Dateitypen Assemblys, die bereits im Verzeichnis Bin vorhanden sind	Diese Dateien werden unverändert in die Ausgabeverzeichnisse kopiert.

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

Dateityp	Compileraktion
ASPX, ASMX, ASHX, . master	Diese Dateien sind in Markup- und Quellcode unterteilt, die sowohl CodeBehind-Dateien als auch Code enthalten, der in <skript runat="server"> -Elemente eingeschlossen ist. Der Quellcode wird in Assemblys mit Namen kompiliert, die von einem Hashalgorithmus abgeleitet sind. Die resultierenden Assemblys werden im Verzeichnis Bin platziert. Jeder Inlinecode, d. h. Code, der zwischen den < Klammern % und %> eingeschlossen ist, ist im Markup enthalten und nicht kompiliert. Der Compiler erstellt neue Dateien, die das Markup mit demselben Namen wie die Quelldateien enthalten. Diese resultierenden Dateien werden im Verzeichnis Bin abgelegt. Der Compiler erstellt auch Dateien mit demselben Namen wie die Quelldateien, aber mit der Erweiterung . KOMPILIERT, die Zuordnungsinformationen enthalten. Das. KOMPILIERTE Dateien werden in den Ausgabeverzeichnissen platziert, die dem ursprünglichen Speicherort der Quelldateien entsprechen.
.ascx	Diese Dateien sind in Markup und Quellcode unterteilt. Quellcode wird in Assemblys kompiliert und im Verzeichnis Bin mit Namen platziert, die von einem Hashalgorithmus abgeleitet werden. Es werden keine Markupdateien generiert.
CS, VB, JSL, CPP (ohne CodeBehind-Dateien für die zuvor aufgeführten Dateitypen)	Quellcode, auf den von den Assemblys verwiesen wird, die aus ASCX-, ASHX- oder ASPX-Dateien 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 nach Dateityp, auf dem sie basieren, kann der Compiler Zuordnungsdateien in den Ausgabeverzeichnissen platzieren.
Dateien im unterverzeichnis App_Code	Quellcodedateien in diesem Unterverzeichnis werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt.
Dateien im unterverzeichnis App_GlobalResources	Diese Dateien werden in Assemblys kompiliert und im Verzeichnis Bin abgelegt. Unter dem Standard Ausgabeverzeichnis wird kein App_GlobalResources Unterverzeichnis erstellt. Wenn die Konfigurationsdatei appliesTo="All" angibt, werden RESX- und RESOURCES-Dateien in die Ausgabeverzeichnisse kopiert. Sie werden nicht kopiert, wenn von einem BuildProvider darauf verwiesen wird.
RESX- und RESSOURCENDATEIEN im Unterverzeichnis App_LocalResources	Diese Dateien werden zu Assemblys mit eindeutigen Namen kompiliert und im Verzeichnis Bin abgelegt. Es werden keine RESX- oder RESOURCE-Dateien in die Ausgabeverzeichnisse kopiert.
SKIN-Dateien im unterverzeichnis App_Themes	Designs werden in Assemblys kompiliert und im Verzeichnis Bin platziert. Stubdateien 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 Assemblys, die bereits im Verzeichnis Bin vorhanden sind	Diese Dateien werden unverändert in das Ausgabeverzeichnis kopiert.

Feste Assemblynamen

Einige Szenarien, z. B. die Bereitstellung einer Webanwendung mit dem MSI Windows Installer, erfordern die Verwendung konsistenter Dateinamen und Inhalte sowie konsistenter Verzeichnisstrukturen, um Assemblys oder Konfigurationseinstellungen für Updates zu identifizieren. In diesen Fällen können Sie die Option -fixednames verwenden, um anzugeben, dass das ASP.NET Kompilierungstool eine Assembly für jede Quelldatei kompilieren soll, anstatt die zu assemblys kompilieren, in der mehrere Seiten kompiliert werden. Dies kann zu einer großen Anzahl von Assemblys führen. Wenn Sie sich also mit Der Skalierbarkeit befassen, sollten Sie diese Option mit Vorsicht verwenden.

Kompilierung mit starkem Namen

Die Optionen -aptca, -delaysign, -keycontainer und -keyfile werden bereitgestellt, sodass Sie Aspnet_compiler.exe verwenden können, um Assemblys mit starkem Namen zu erstellen, ohne das Strong Name Tool (Sn.exe) separat zu verwenden. Diese Optionen entsprechen allowPartiallyTrustedCallersAttribute, AssemblyDelaySignAttribute, AssemblyKeyNameAttribute und AssemblyKeyFileAttribute.

Die Erörterung dieser Attribute liegt außerhalb des Rahmens dieses Kurses.

Labs

Jedes der folgenden Labs baut auf den vorherigen Labs auf. Sie müssen sie in der richtigen Reihenfolge ausführen.

Lab 1: Verwenden der Konfigurations-API

1. Erstellen Sie eine neue Website namens mod9lab.
2. Fügen Sie der Website eine neue Webkonfigurationsdatei hinzu.
3. Fügen Sie der datei web.config Folgendes hinzu:

<authorization>
    <deny users="?"/>
</authorization>

<identity impersonate="true"/>

Dadurch wird sichergestellt, dass Sie über die Berechtigung zum Speichern von Änderungen an der web.config Datei verfügen.

1. Fügen Sie default.aspx ein neues Label-Steuerelement hinzu, und ändern Sie die ID in lblDebugStatus.
2. Fügen Sie "Default.aspx" ein neues Button-Steuerelement hinzu.
3. Ändern Sie die ID des Button-Steuerelements in btnToggleDebug und text in Debugstatus umschalten.
4. Öffnen Sie die Codeansicht für die CodeBehind-Datei default.aspx, und fügen Sie eine using-Anweisung für System.Web.Configuration wie folgt hinzu:

using System.Web.Configuration;

1. Fügen Sie der -Klasse zwei private Variablen und eine Page_Init-Methode hinzu, wie unten gezeigt:

public partial class _Default : System.Web.UI.Page {
    private bool _debugStatus;
    private CompilationSection compilation;
    private Configuration config;
    protected void Page_Init(object sender, EventArgs e) {
        config = WebConfigurationManager.OpenWebConfiguration("/mod9lab");
        compilation =
            (CompilationSection)config.GetSection("system.web/compilation");
        _debugStatus = compilation.Debug;
    }
}

1. Fügen Sie den folgenden Code zu Page_Load hinzu:

lblDebugStatus.Text = "Debug set to: " + _debugStatus.ToString();

1. Speichern und durchsuchen Sie default.aspx. Beachten Sie, dass das Label-Steuerelement die aktuelle Debug-status anzeigt.
2. Doppelklicken Sie im Designer auf das Button-Steuerelement, und fügen Sie dem Click-Ereignis für das Button-Steuerelement den folgenden Code hinzu:

compilation.Debug = !_debugStatus;
config.Save();
lblDebugStatus.Text = "Debug set to: " + compilation.Debug.ToString();

1. Speichern Und durchsuchen Sie default.aspx, und klicken Sie auf die Schaltfläche.
2. Öffnen Sie die web.config Datei, nachdem Sie auf die einzelnen Schaltflächen geklickt haben, und beobachten Sie das Debug-Attribut im <Kompilierungsabschnitt> .

Lab 2: Protokollieren von Anwendungsneustarts

In diesem Lab erstellen Sie Code, mit dem Sie die Protokollierung von Herunterfahren von Anwendungen, Start-ups und Neukompilierungen im Ereignisanzeige umschalten können.

1. Fügen Sie eine DropDownList zu default.aspx hinzu, und ändern Sie die ID in ddlLogAppEvents.
2. Legen Sie die AutoPostBack-Eigenschaft für dropDownList auf true fest.
3. Fügen Sie der Items-Auflistung für dropDownList drei Elemente hinzu. Legen Sie den Text für das erste Element Wert und den Wert -1 fest. Geben Sie text andvalue of the second item true and the Text and Value of the third item False an.
4. Fügen Sie eine neue Bezeichnung zu default.aspx hinzu. Ändern Sie die ID in lblLogAppEvents.
5. Öffnen Sie die CodeBehind-Ansicht für default.aspx, und fügen Sie eine neue Deklaration für eine Variable vom Typ HealthMonitoringSection hinzu, wie unten gezeigt:

public partial class _Default : System.Web.UI.Page {
    private bool _debugStatus;
    private CompilationSection compilation;
    private Configuration config;

    // new variable below
    private HealthMonitoringSection health;
}

1. Fügen Sie dem vorhandenen Code in Page_Init den folgenden Code hinzu:

health = (HealthMonitoringSection)config.GetSection("system.web/healthMonitoring");

1. Doppelklicken Sie auf dropDownList, und fügen Sie dem SelectedIndexChanged-Ereignis den folgenden Code hinzu:

if (ddlLogAppEvents.SelectedValue != "-1") {
    if (Convert.ToBoolean(ddlLogAppEvents.SelectedValue)) {
        RuleSettings appRules = new
        RuleSettings("AppRestartEvents",
        "Application Lifetime Events",
        "EventLogProvider");
        health.Rules.Add(appRules);
        config.Save();
    } else {
        health.Rules.Remove("AppRestartEvents");
        config.Save();
    }
}

1. Durchsuchen Sie default.aspx.

2. Legen Sie die Dropdownliste auf False fest.

3. Löschen Sie das Anwendungsprotokoll im Ereignisanzeige.

4. Klicken Sie auf die Schaltfläche, um das Debug-Attribut für die Anwendung zu ändern.

5. Aktualisieren Sie das Anwendungsprotokoll im Ereignisanzeige.

   1. Wurden Ereignisse protokolliert?
   2. Warum oder warum nicht?

6. Legen Sie die Dropdownliste auf True fest.

7. Klicken Sie auf die Schaltfläche, um das Debug-Attribut für die Anwendung umzuschalten.

8. Aktualisieren Sie die Anwendungsanmeldung für die Ereignisanzeige.

   1. Wurden Ereignisse protokolliert?
   2. Was war der Grund für das Herunterfahren der App?

9. Experimentieren Sie mit dem Aktivieren und Deaktivieren der Protokollierung, und sehen Sie sich die Änderungen an der web.config-Datei an.

Weitere Informationen:

ASP.NET 2.0-Anbietermodells ermöglicht es Ihnen, eigene Anbieter nicht nur für die Anwendungsinstrumentation, sondern auch für viele andere Zwecke wie Mitgliedschaft, Profile usw. zu erstellen. Ausführliche Informationen zum Schreiben eines benutzerdefinierten Anbieters zum Protokollieren von Anwendungsereignissen in einer Textdatei finden Sie unter diesem Link.