Planungsschritt 2: Planen von ASP.NET Einstellungen

von Keith Newman und Robert McMurray

2.1. Sitzungszustandseinstellungen

Wenn Clients eine Website besuchen, navigieren sie in der Regel von einer Seite zu einer anderen und ändern häufig einige der besuchten Seiten. Wenn Sie die Seiten nachverfolgen möchten, die Benutzer und Benutzerinnen durchsuchen, sowie die Änderungen, die sie beim Besuchen der Website vornehmen, konfigurieren Sie den Sitzungszustand.

Wenn der Sitzungszustand für eine Anwendung aktiviert ist, erhält der Benutzer oder die Benutzerin bei der ersten Anforderung einer Webseite von Ihrer ASP.NET-Anwendung eine eindeutige Sitzungs-ID. Sitzungszustandsdaten werden mit einem der folgenden Verfahren auf dem Server gespeichert:

• In-Process: Der Sitzungszustand wird im Arbeitsprozess gespeichert, in dem die ASP.NET-Anwendung ausgeführt wird.
• Zustandsserver: Der Sitzungszustand wird außerhalb des Arbeitsprozesses gespeichert, in dem die ASP.NET-Anwendung ausgeführt wird.
• SQL Server: Der Sitzungszustand wird in einer SQL Server-Datenbank gespeichert.

Sitzungszustandsdaten können auch auf dem Client in einem Cookie gespeichert werden. Ein Cookie ist eine Textdatei mit Daten, die zum Speichern von Informationen zu den Benutzern/Benutzerinnen verwendet werden, z. B. Benutzereinstellungen und Informationen zur Benutzerauthentifizierung.

In den folgenden Abschnitten werden die Optionen für den Sitzungszustandsspeicher ausführlicher beschrieben.

• Speichern des Sitzungszustands „In-Process“
• Speichern des Sitzungszustands mithilfe eines Zustandsservers
• Speichern des Sitzungszustands mithilfe von SQL Server
• Cookiemodus für Sitzungszustand

Speichern des Sitzungszustands „In-Process“

Im Sitzungszustandsmodus „In-Process“ werden Sitzungszustandsdaten für eine ASP.NET-Anwendung in dem Arbeitsprozess gespeichert, in dem die Anwendung ausgeführt wird. Dieser Modus ist die Standardeinstellung für IIS 8.

Der In-Process-Sitzungszustand hat den Vorteil, dass er den schnellsten Zugriff auf Sitzungszustandsdaten ermöglicht. Je mehr Daten Sie in einer Sitzung speichern, desto mehr Arbeitsspeicher verbrauchen Sie auch, wodurch die Serverleistung beeinträchtigt werden kann.

Bevor Sie den In-Process-Sitzungszustand konfigurieren, sollten Sie die Auswirkungen abwägen, die eine Wiederverwendung des Arbeitsprozesses auf Sitzungszustandsdaten hat. Bei der Wiederverwendung des Arbeitsprozesses gehen alle Sitzungszustandsdaten verloren. Wenn Ihre ASP.NET-Anwendungen Sitzungszustandsdaten beibehalten müssen und schneller Zugriff auf die Daten nicht Ihr Hauptziel ist, erwägen Sie die Verwendung eines Out-of-Process-Sitzungszustandsmodus für das Speichern dieser Daten.

Standardmäßig läuft eine Sitzung ab, wenn der Benutzer oder die Benutzerin eine Seite in der ASP.NET-Anwendung 20 Minuten lang nicht angefordert oder aktualisiert hat. Da Sitzungsobjekte Arbeitsspeicher auf dem Webserver verbrauchen, verringern Sie ggf. den Timeoutwert, um Ressourcen zu sparen.

Gehen Sie beim Anpassen des Timeoutwerts für Sitzungen vorsichtig vor, da die im Sitzungsobjekt der Benutzer/Benutzerinnen gespeicherten Informationen verloren gehen, wenn sie für die Dauer des Timeoutzeitraums nicht auf der Website aktiv sind.

Wenn Sie sich für eine In-Process-Speicherung von Sitzungszustandsdaten entscheiden, legen Sie auch fest, ob Sie Cookies verwenden möchten. Weitere Informationen zu Cookies finden Sie unter Cookiemodus für Sitzungszustand.

Speichern des Sitzungszustands mithilfe eines Zustandsservers

Ein Zustandsserver speichert Sitzungszustandsdaten in Arbeitsspeicher außerhalb des Arbeitsprozesses. Der Vorteil dieser Konfiguration besteht darin, dass der Sitzungszustand beibehalten wird, wenn der Arbeitsprozess der Anwendung wiederverwendet wird. Die Verwendung eines Zustandsservers wird für Anwendungen mittlerer Größe empfohlen.

Ein Zustandsserver ist vom Windows-Zustandsdienst („Aspnet_state.exe“) abhängig und erfordert einen Computerschlüssel, um den Sitzungszustand über die Verbindung zu überprüfen.

Wenn ein Zustandsserver auf dem gleichen Webserver ausgeführt wird, der auch die Anwendungen enthält, für die der Status gespeichert wird, wird eine Webgartenkonfiguration unterstützt. Um den Schutz von Sitzungszustandsdaten zu verbessern, können Sie eine Webfarmkonfiguration mit einem separaten Server verwenden, der Sitzungszustandsdaten speichert und für alle Server in der Farm freigibt. Eine andere Möglichkeit ist die Verwendung von SQL Server zum Speichern des Out-of-Process-Sitzungszustands.

Wichtig: Der Windows-Zustandsdienst („Aspnet_state.exe“) muss ausgeführt werden, damit der In-Process-Sitzungszustand wirksam wird. Dieser Dienst wird standardmäßig installiert, wenn Windows Server 2012 installiert und für den manuellen Start konfiguriert wird. Ändern Sie das Startverhalten in „Automatisch“.

Wenn Sie den Sitzungszustand mithilfe eines Zustandsservers speichern möchten, treffen Sie die folgenden Entwurfsentscheidungen:

• Definieren Sie eine Verbindungszeichenfolge für den Zustandsserver.
• Geben Sie die Anzahl der Sekunden vor dem Timeout der Verbindung an.
• Entscheiden Sie, ob die Komprimierung aktiviert werden soll.
• Entscheiden Sie, ob Sitzungszustandsdaten in einem Cookie gespeichert werden sollen. Weitere Informationen zu Cookies finden Sie unter Cookiemodus für Sitzungszustand.

Speichern des Sitzungszustands mithilfe von SQL Server

Einer der Out-of-Process-Sitzungszustandstypen verwendet einen SQL-Server zum Speichern von Sitzungszustandsdaten. Der Vorteil dieser Konfiguration besteht darin, dass der Sitzungszustand auch dann erhalten bleibt, wenn der Arbeitsprozess der Anwendung wiederverwendet wird oder der Windows-Zustandsdienst oder der Webserver ausfällt.

Wenn ein SQL-Server auf demselben Webserver ausgeführt wird wie die Anwendungen, deren Zustand er speichert, unterstützt er eine Webgartenkonfiguration, wodurch die Skalierbarkeit des Servers erhöht wird. Wenn der SQL Server auf einem anderen Server ausgeführt wird, unterstützt er eine Webfarmkonfiguration, wodurch die Skalierbarkeit für eine Gruppe von Servern erheblich verbessert wird.

Wenn Sie den Sitzungszustand in einer SQL Server-Datenbank speichern möchten, treffen Sie die folgenden Entwurfsentscheidungen:

• Definieren Sie eine Verbindungszeichenfolge für die Datenbank.
• Geben Sie die Anzahl der Sekunden vor dem Timeout der Verbindung an.
• Geben Sie die Anzahl der Sekunden vor dem Versuch einer Verbindungswiederherstellung an.
• Entscheiden Sie, ob eine benutzerdefinierte Datenbank aktiviert werden soll.
• Entscheiden Sie, ob die Komprimierung aktiviert werden soll.
• Entscheiden Sie, ob Sitzungszustandsdaten in einem Cookie gespeichert werden sollen. Weitere Informationen zu Cookies finden Sie unter Cookiemodus für Sitzungszustand.

Cookiemodus für Sitzungszustand

Eine Möglichkeit zum Nachverfolgen des Sitzungszustands für Clients, die eine Verbindung mit einem Webserver herstellen, ist die Verwendung von Cookies. Sie können einen Webserver so konfigurieren, dass Cookies verwendet werden, dass keine Cookies verwendet werden oder dass das Cookieverhalten abhängig vom Browser ausgewählt werden soll, über den die Verbindung hergestellt wird.

Ein Sitzungscookie ordnet Sitzungsinformationen Clientinformationen für die Sitzung zu. Eine Sitzung ist die Dauer der Verbindung eines Benutzers oder einer Benutzerin mit einer Website. Das Cookie wird zusammen mit allen Anforderungen zwischen einem Client und einem Webserver in einen HTTP-Header übergeben.

Die Verwendung von Cookies zum Nachverfolgen des Sitzungszustands ist effizienter als alle anderen Methoden ohne Cookies, da für Cookies keine Umleitung erforderlich ist. Darüber hinaus ermöglichen sie Benutzern und Benutzerinnen, Webseiten mit Lesezeichen zu versehen, und sie behalten den Status bei, wenn die Benutzer/Benutzerinnen eine Website verlassen, um eine andere zu besuchen, und dann zur ursprünglichen Website zurückkehren. Der einzige Nachteil von Benutzercookies besteht darin, dass Cookies im Browser deaktiviert werden können.

Im Cookiemodus Geräteprofil verwenden verwendet der Browser Cookies, wenn Cookies vom Browser unterstützt werden; andernfalls werden keine Cookies verwendet. Wenn das Geräteprofil die Unterstützung von Cookies angibt, werden sie unabhängig davon verwendet, ob der Benutzer bzw. die Benutzerin die Cookieunterstützung deaktiviert hat.

Im Cookiemodus Automatische Erkennung verwendet das mobile Gerät Cookies, wenn sein Profil Cookies unterstützt; andernfalls werden keine Cookies verwendet. Im Fall von Desktopbrowsern, die bekanntermaßen Unterstützung für Cookies bieten, versucht ASP.NET, Cookies zu verwenden, wenn Cookieunterstützung im Browser aktiviert ist. Wenn die Cookieunterstützung deaktiviert ist, wird der Sitzungszustand in der URL gespeichert.

Sie können den Sitzungszustand konfigurieren, ohne Cookies zu verwenden. Wenn Sie den Sitzungszustand mithilfe eines URI (Uniform Resource Identifier) verarbeiten, wird die Sitzungs-ID als Abfragezeichenfolge in die URI-Anforderung eingebettet. Anschließend wird der URI zur ursprünglich angeforderten URL umgeleitet. Die geänderte URI-Anforderung wird für die Dauer der Sitzung verwendet, sodass kein Cookie notwendig ist.

Durch die Verwendung eines URI zur Nachverfolgung des Sitzungszustands können Sie die Nachteile von Cookies umgehen, z. B. Probleme mit der Browserunterstützung und die Möglichkeit, dass Benutzer/Benutzerinnen Cookies deaktivieren. Ein URI hat jedoch die folgenden Nachteile:

• Absolute URLs können nicht ohne Verlust des Sitzungszustands verwendet werden, d. h., wenn ein Benutzer oder eine Benutzerin zu einer anderen Anwendung wechselt und dann zur vorherigen zurückkehrt, sind die Eingaben nicht mehr auf der Seite vorhanden.
• Benutzer und Benutzerinnen können Webseiten nicht mit Lesezeichen versehen, da der Sitzungszustand verloren geht.

Wenn Sie Cookies zum Speichern des Sitzungszustands verwenden möchten, treffen Sie die folgenden Entwurfsentscheidungen:

• Wählen Sie einen Cookiemodus aus: „Automatische Erkennung“, „Cookies verwenden“, „Geräteprofil verwenden“ oder „URI verwenden“.
• Geben Sie den Namen des Cookies an, sofern Sie nicht „URI verwenden“ ausgewählt haben.
• Geben Sie die Anzahl der Minuten bis zum Timeout des Cookies an, sofern Sie nicht „URI verwenden“ ausgewählt haben.
• Legen Sie fest, ob eine abgelaufene Sitzungs-ID neu generiert werden soll, sofern Sie nicht „Cookies verwenden“ ausgewählt haben.

2.2. Seiten- und Steuerelementeinstellungen

ASP.NET-Seiten enthalten zusätzliche Elemente, die von ASP.NET erkannt und verarbeitet werden, wenn die Seite ausgeführt wird. ASP.NET-Seiten können auch benutzerdefinierte, wiederverwendbares Steuerelemente enthalten. Diese benutzerdefinierten Steuerelemente werden auf dem Server verarbeitet. Dies ermöglicht Ihnen die Verwendung von Servercode, um Eigenschaften von ASP.NET-Webseiten festzulegen.

In IIS 8 können Sie die folgenden ASP.NET-Einstellungen für Seiten- und Benutzersteuerelemente konfigurieren:

• Verhaltenseinstellungen: Beispielsweise, ob die Webseite ihren Anzeigezustand und den Anzeigezustand aller enthaltenen Serversteuerelemente speichert, wenn die aktuelle Seitenanforderung endet.
• Allgemeine Einstellungen: Beispielsweise Namespaces, die für alle Seiten eingeschlossen werden.
• Kompilierungseinstellungen: Beispielsweise, ob Seiten kompiliert oder interpretiert werden.
• Dienste: Beispielsweise, ob der Sitzungszustand aktiviert ist.

In IIS 8 stehen Standardeinstellungen für ASP.NET-Seiten und -Steuerelemente zur Verfügung, Sie können diese Einstellungen jedoch nach Bedarf ändern. Sie können z. B. die Masterseitendatei für eine Website festlegen oder den Anzeigezustand aktivieren

Benutzerdefinierte Websteuerelemente sind kompilierte Komponenten, die auf dem Server ausgeführt werden und Benutzeroberflächenfunktionen und andere verwandte Funktionen in wiederverwendbaren Paketen kapseln. In IIS 8 können Sie die Zuordnung von Tagpräfix und Namespace für ein benutzerdefiniertes Steuerelement angeben, das auf mehreren Seiten in einer Anwendung verwendet werden kann.

Fügen Sie ein benutzerdefiniertes Steuerelement hinzu, wenn Sie die Tagpräfix-Namespace-Zuordnung für ein benutzerdefiniertes Steuerelement angeben möchten, das auf mehreren Seiten in einer Anwendung verwendet wird.

Wenn Sie benutzerdefinierte ASP.NET-Steuerelemente konfigurieren möchten, benötigen Sie für jedes zu konfigurierende Steuerelement die folgenden Informationen:

• Geben Sie das Tagpräfix des Steuerelements an.
• Geben Sie den .NET-Namespace des Steuerelements an.
• Geben Sie die Assembly an, in der sich das Steuerelement befindet.

2.3. Anwendungseinstellungen

Konfigurieren Sie Anwendungseinstellungen, wenn Sie Schlüssel-Wert-Paare als Teil der Konfiguration in der Datei „Web.config“ speichern möchten. Anwendungseinstellungen bieten schnellen und einfachen Zugriff auf gespeicherte Konfigurationsdaten für die Anwendung.

Um benutzerdefinierte Steuerelemente zu verwalten, können Sie eine Liste anzeigen, die alle benutzerdefinierten Steuerelemente für eine bestimmte Konfigurationsebene enthält. Sie können diese Liste nach Tagpräfix, Quelle oder Assembly oder nach Bereich (lokal oder geerbt) sortieren. Außerdem können Sie Steuerelemente nach Bereich gruppieren, um festzustellen, welche benutzerdefinierten Steuerelemente auf der aktuellen Konfigurationsebene gelten und welche benutzerdefinierten Steuerelemente von einer übergeordneten Ebene geerbt wurden.

Fügen Sie ein benutzerdefiniertes Steuerelement hinzu, wenn Sie die Tagpräfix-Namespace-Zuordnung für ein benutzerdefiniertes Steuerelement angeben möchten, das auf mehreren Seiten in einer Anwendung verwendet wird.

Wenn Sie Anwendungseinstellungen konfigurieren möchten, benötigen Sie für jede zu konfigurierende Einstellung die folgenden Informationen:

1. Geben Sie einen Namen für die Einstellung an.
2. Geben Sie einen Wert für die Einstellung an.

2.4. .NET-Kompilierungseinstellungen

Damit Anwendungscode Anforderungen von Benutzern und Benutzerinnen verarbeiten kann, muss der Code zunächst von ASP.NET in mindestens einer Assembly kompiliert werden. Assemblys sind Dateien mit der Dateiendung „.dll“. Konfigurieren Sie .NET-Kompilierungseinstellungen in IIS 8, wenn Sie steuern möchten, wie ASP.NET-Code kompiliert werden soll.

In IIS können Sie die folgenden .NET-Kompilierungseinstellungen konfigurieren:

• Batcheinstellungen wie z. B. die maximale Dateigröße für Batches und die maximale Anzahl von Seiten pro Batchkompilierung.
• Verhaltenseinstellungen wie z. B. die Angabe, wie oft Ressourcen dynamisch kompiliert werden, bevor die Anwendung neu gestartet wird.
• Allgemeine Einstellungen wie z. B. die Standardprogrammiersprache für dynamisch kompilierte Dateien.

2.5. .NET-Globalisierungseinstellungen

Globalisierung ist der Prozess der Internationalisierung von Anwendungscode und die anschließende Lokalisierung der Anwendung in andere Sprachen und Kulturen. Der Internationalisierungsprozess ermöglicht, Anwendungsinhalte für jedes Gebietsschema zu übersetzen, zu speichern, abzurufen und anzuzeigen, wobei nach Möglichkeit stets dieselbe Anwendunscodebasis verwendet wird. Das Gebietsschema ist die Kombination aus Sprache und kultureller Umgebung. Dazu gehören Datums- und Uhrzeitformate, Währungen, Telefonnummern usw. Lokalisierung bezeichnet die Anpassung der Anwendung an andere Gebietsschemas durch Übersetzen und Formatieren von Inhalt gemäß der Kultur, vorzugsweise ohne Änderung des Codes.

Sie können die Globalisierungseinstellungen für ASP.NET-Anwendungen auf Webserverebene ändern, wenn sie für alle ASP.NET-Anwendungen auf dem Server gelten sollen. Außerdem können Sie ASP.NET-Globalisierungseinstellungen für Websites, Anwendungen, Verzeichnisse und Dateien bearbeiten.

In IIS können Sie die folgenden Globalisierungseinstellungen konfigurieren:

• Kulturelle Einstellungen wie z. B. die Benutzeroberflächenkultur oder die Benutzeroberflächensprache
• Codierungseinstellungen wie z. B. die Codierung für Antwortheader