Leistungen
Leistungen
Überblick
Leistungsangebot
Kernkompetenzen
Schulungsthemen
In-House-Schulungen
Offene .NET-Seminare
Offene WPS-Seminare
Beratung
Coaching
Support
Softwareentwicklung
Entwickler-Vermittlung
.NET/Visual Studio
TFS/ALM/Scrum
Webprogrammierung
PowerShell
Konditionen
Anfrage/Kontakt
Beratung/Coaching
Beratung/Coaching
Beratungsthemen
Coaching
Unsere Berater
Referenzkunden
Konditionen
Angebotsanfrage
In-House-Schulungen
In-House-Schulungen
Überblick
Themen/Fachgebiete
Schulungskonfigurator
Konzepte
.NET/Visual Studio
C#
VB.NET
ASP.NET
Moderne Webanwendungen
TFS/ALM/Scrum
PowerShell
Konferenzvortraege
Referenzkunden
Unsere Trainer
Konditionen
Angebotsanfrage
Offene Schulungen
Offene Schulungen
Überblick .NET-Seminare
.NET/C#-Basisseminar
WPF (Desktop)
ASP.NET/AJAX (Web)
WCF/WF (SOA)
ADO.NET/EF (Data)
Windows PowerShell
.NET, C#, VB, Visual Studio
.NET, C#, VB, Visual Studio
Startseite
Beratung/Training
Offene .NET-Seminare
Einführung
Lexikon
Artikel
Bücher
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
World Wide Wings Demo
Codebeispiele
Scripting
ASP.NET
.NET 2.0
.NET 3.0/3.5
.NET 4.0/4.5
Community
Forum
Kommerzielle Leistungen
ASP.NET
ASP.NET
Startseite
Lexikon
Sicherheit
Konfiguration
Global.asax
Tracing
Technische Beiträge
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
PowerShell
PowerShell
Überblick
Beratung
In-House-Schulungen
Öffentliche Schulungen
Codebeispiele
Commandlet Extensions
Offene PowerShell-Seminare
Inhouse-Seminare
Windows
Windows
Startseite
Windows Runtime (WinRT)
Windows PowerShell
Windows Scripting
Windows-Schulungen
Windows-Lexikon
Windows-Forum
Windows Scripting
Windows Scripting
Startseite
Lexikon
FAQ
Buecher
Architektur
Skriptsprachen
Scripting-Hosts
Scripting-Komponenten
COM/DCOM/COM+
ADSI
WMI
Scripting-Tools
WSH-Editoren
Codebeispiele
ASP.NET
.NET-Scripting
Forum
Links
Kommerzielle Leistungen
Service
Service
Website-FAQ
Anmeldung/Login
Leser-Registrierung
Gast-Registrierung
Nachrichten/RSS
Newsletter
Foren
Weblog
Lexikon
Downloads
Support
Kontakt
Site Map
Suche
Literaturtipps
Publikationen
Publikationen
Redaktionsbüro
Bücher
Fachartikel
Leser-Portal
Autoren gesucht!
Rezensionen
Über uns
Über uns
Holger Schwichtenberg
Team
Referenzkunden
Kundenaussagen
Referenzprojekte
Partner
Site Map
Suche
Weitere Websites
Tag Cloud
Impressum
Rechtliches
Datenschutzerklärung

Konfiguration ASP.NET-Webanwendungen

ASP.NET-Anwendungen installieren und konfigurieren

Um ASP.NET-Anwendungen zu installieren und zu konfigurieren stehen dem Entwickler und Administrator leistungsfähige, aber dennoch einfache Instrumente zur Verfügung. Die eigentliche Installation einer ASP.NET-Anwendung ist dabei faszinierend einfach. Die eigentliche Konfiguration der Anwendung bzw. Anpassungen an deren Konfiguration lassen sehr sich individuell und umfassend über XML-Dateien, den Konfigurationsdateien (Web.config und Machine.config) realisieren.

Installation von ASP.NET-Anwendungen

ASP.NET-Anwendungen unterscheiden sich bezüglich ihres Installationsaufwandes nicht von anderen .NET-Anwendungen. Eine XCOPY-Installation in den entsprechenden Ordner des Internetservers reicht in der Regel aus um eine bestehende ASP.NET-Anwendung auf dem Internetserver zu installieren. Dies setzt selbstverständlich eine Installation des .NET Framework voraus.

Das Anwendungsverzeichnis muss lediglich für den Zugriff über den Internet-Informationsdienst freigegeben werden. Dies lässt sich einerseits über den Internet Informationsdienst-Manager realisieren, indem für den entsprechenden Ordner ein virtuelles Verzeichnis mit IIS-Anwendung (Registerkarte Verzeichnis, Sektion Anwendungseinstellungen) zu erstellen.

Abbildung 1:
Anlegen einer IIS-Anwendung im Internet-Informationsdienst-Manager

 

Alternativ ist es auch möglich, das virtuelle Verzeichnis über den Eigenschaftsdialog innerhalb des Windows Explorers anzulegen.

Abbildung 2:
Anlegen einer IIS-Anwendung im Windows Explorer

Tipp

Installationstechnisch wäre damit eine Anwendung sofort lauffähig. Damit eine Anwendung portabel und maschinenneutral installierbar ist, muss während der Entwicklung darauf geachtet werden, dass möglichst keine absoluten Pfade zu URL-Ressourcen und sonstigen Dateien (Datenbankdateien, Textdateien, XML-Dateien), sowie keine statischen Servernamen (z.B. Active Directory-Domänencontroller) verwendet werden. Es sollte jederzeit möglich sein, solche Einstellungen von "außen" zentral zu konfigurieren und verändern zu können, und diese nicht innerhalb des Codes "hart" zu implementieren. Wie dies geschehen kann wird im Abschnitt ì "Benutzerdefinierte Konfigurationseinträge" noch genau erläutert.

 

Konfigurationsdateien

Den zentralen Kern jeder ASP.NET-Anwendung bilden Konfigurationsdateien. Dabei handelt es sich um XML-Dateien, die über vordefinierte XML-Elemente diverse Konfigurationsmöglichkeiten erlauben. Dieser Mechanismus ist nicht speziell für ASP.NET-Anwendungen, sondern gilt für alle Formen von .NET-Anwendungen.

Machine.config

Auf der Ebene der Maschine sorgt die Datei Machine.config für eine systemweite Konfiguration, die für alle .NET-Anwendungen und damit auch ASP.NET-Anwendungen auf einem Computer gilt. Die Datei befindet sich im Verzeichnis  %Systemroot%\Microsoft.NET\Framework\v1.0.xxxx\CONFIG.

Tipp

Mit dieser Datei erhält man neben einer guten Übersicht über alle vorhanden Konfigurationselemente und den Klassen, die für die entsprechende Handhabung verantwortlich sind. Ein Blick in die Datei machine.config bietet die Möglichkeit, die Grundkonfiguration von ASP.NET-Anwendungen zu untersuchen.

Web.config

Konfigurationsdateien für einzelne ASP.NET-Anwendungen tragen immer den Namen Web.config. Mittels dieser lassen sich Konfigurationseinstellungen der systemweiten Maschinenkonfiguration (Machine.config) überschreiben. Eine web.config-Datei kann innerhalb der Site, einer einzelnen Anwendungen oder aber auch in beliebigen Unterverzeichnissen sein. Die Definition einer Web.config-Datei ist nicht Pflicht. Wird keine entsprechende Datei verwendet, so werden alle Eigenschaften von der Machine.config unverändert übernommen. Zwar ist es nur möglich, eine Web.config-Datei pro Verzeichnis zu verwenden. Innerhalb von Unterverzeichnissen dürfen allerdings ebenfalls entsprechende Dateien verwendet werden. Und da es sich dabei bei um einen hierarchischen Konfigurationsmechanismus handelt, werden alle Einstellungen der Konfigurationsdateien übergeordneter Verzeichnisse übernommen und gegebenenfalls überschrieben.

Führt man zur Laufzeit der ASP.NET-Anwendungen Änderungen an dieser Datei durch, so werden diese in der Regel sofort erkannt und übernommen. Ein Neustart ist dafür nicht notwendig. Dieses Verhalten trifft für (fast) alle Einstellungen zu, allerdings gibt es auch einige Ausnahmen, auf die an anderer Stelle noch eingegangen wird.

Werkzeugunterstützung

Visual Studio .NET bietet für die Veränderungen der XML-basierten Konfigurationsdateien von ASP.NET nicht mehr als den eingebauten XML-Editor. Ein komfortableres Werkzeug ist der Web.Config Editor (WCE). Der WCE wird in Kapitel 2 kurz vorgestellt.

Konfigurationsebenen

Für ASP.NET können Konfigurationen hierarchisch auf den folgenden Ebenen definiert werden: Maschine à Website à Anwendung à Verzeichnis. Jede Ebene übernimmt grundsätzlich die Konfiguration ihrer übergeordneten Ebene, allerdings können die meisten Einstellungen auf jeder Ebene überschrieben werden.

Abbildung 3:Konfigurationsebenen

Wichtig für das Verständnis ist, dass es die hierarchische Vererbung von Konfigurationsdateien auf virtuellen Verzeichnissen beruht, also URL-Pfaden und nicht den physikalischen Dateipfaden.

Die Anwendung mit dem URL-Pfad http://localhost/abc/Anwendung1/ (Dateipfad C:\InetPub\wwwroot\Anwendung1) erbt die Konfiguration vom URL-Pfad http://localhost/abc/ (Dateipfad C:\InetPub\wwwroot\misc\abc), obwohl die Verzeichnishierarchie im Dateisystem anders ist.

Konfigurationselemente

Da Konfigurationseinstellungen sich mittels XML-Dateien definieren lassen, können die Informationen sehr einfach gelesen und verändert werden. Innerhalb dieser Dateien befinden sich vordefinierte XML-Elemente die für diverse Aspekte von .NET-Anwendungen und deren Umgebung zuständig sind. Mittels dieser Elemente können Konfigurationsattribute und weitere Unterdielemente beinhaltet sein, die für Teilaspekte verwendet werden.

Die folgende Tabelle zeigt eine kurze und unvollständige Liste von Elementen, die innerhalb der Konfigurationsdateien verwendet werden können. Für detaillierte Informationen muss hier allerdings auf die ì .NET Framework Dokumentation verwiesen werden, da eine genaue Beschreibung jedes Elements den Umfang dieses Buch sprengen würde.

Tabelle 1: Allgemeine Elemente

Element

Beschreibung

<appSettings>

Benutzerdefinierte Konfigurationseinträge. Hier können beliebige Werte durch den Entwickler hinterlegt werden, die aus einer laufenden Anwendung heraus ausgelesen werden können.

<configSections>

Definition von eigenen Elementen und den für die Behandlung dieser Elemente zuständigen Klassen. Dadurch lassen sich Konfigurationsdateien durch benutzerdefinierte Elemente erweitern.

<system.diagnostics>

Ermöglicht die Festlegung verschiedener Ablaufverfolgungen und die Form, wie Meldungen gesammelt und präsentiert werden können.

<system.net>

Definiert Einstellungen für Klassen im Namespace System.Net. Dazu gehören, u.a. die Authentifizierungsmodule, die Verbindungsverwaltung, den Proxyserver und Anforderungsverarbeitung für Internethosts.

<system.web>

Kern der ASP.NET-Konfiguration. Hier sind Konfigurationen enthalten, die Definieren, wie sich Anwendungen verhalten sollen.

<system.runtime.remoting>

Beinhaltet Informationen über entfernte Objekte und Kanäle, über welche die Kommunikation zwischen diesen Objekten geführt wird.

Besonders interessant für ASP.NET-Anwendungen sind die Elemente <system.web> und <appSettings>. Auf diese wird in den folgenden Abschnitten noch genauer eingegangen.

Hinweis

Alle Angaben innerhalb von .NET-Konfigurationsdateien sind Case-Sensitiv, unterscheiden also Groß- und Kleinschreibung.

Konfiguration für einzelne Verzeichnisse und Dateien

Alternativ zur Verwendung mehrere Web.config-Dateien in verschiedenen Verzeichnissen ist es möglich, eine Web.config-Datei in verschiedenen Bereichen zu unterteilen. Innerhalb von Web.config-Dateien ist es möglich, für einzelne Unterverzeichnisse oder einzelne Dateien spezielle Konfigurationen anzuwenden, die sich von der normalen Konfiguration unterscheiden. Dadurch lassen sich Teile der Anwendung individuell konfigurieren.

Listing 1:
Datei- und
Verzeichnis-
Konfiguration

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <!-- Konfiguration für deutsche Benutzer -->

  <location path="sub1">

    <system.web>

      <globalization requestEncoding="utf-8"

          responseEncoding="utf-8" culture="de-DE" uiCulture="de-DE" />

    </system.web>

  </location>

  <location path="deutsch.aspx">

    <system.web>

      <globalization requestEncoding="utf-8"

          responseEncoding="utf-8" culture="de-DE" uiCulture="de-DE" />

    </system.web>

  </location>

  <!-- Konfiguration für amerikanische Benutzer -->

  <location path="sub2">

    <system.web>

 

    </system.web>

  </location>

  <!-- Konfiguration für chinesische Benutzer -->

  <location path="sub3">

    <system.web>

     

    </system.web>

  </location>

</configuration>

Die Konfigurationsdatei definiert für verschiedene Unterverzeichnisse und Webforms den zu verwendenden Kulturkreis. Dadurch verwenden diese Anwendungsbereiche (Webform und Verzeichnis) die kulturüblichen Gegebenheiten. Dies wirkt sich beispielsweise auf das Datums- und Währungsformat aus. Dieses Thema wird im Abschnitt ì Globalisierung detaillierter behandelt.

Hinweis

Die Konfigurationsdatei und die weiteren Dateien aus diesem Unterkapitel befinden sich auf der CD-ROM in der Datei /Kapitel05/Konfiguration/Location/Web.config.

Verhindern des Überschreibens von Konfigurationseinstellungen

Die hierarchische Konfigurationsmöglichkeit von Maschinenebene hinunter zu einzelnen Anwendungsverzeichnissen ist sehr praktisch und einfach zu handhaben. Allerdings ist dieses Verhalten nicht immer gewünscht, und darf aus Sicherheitsgründen nicht immer möglich sein. Aus diesem Grund hat der Administrator eines Computers, bzw. der Webmaster der Webfarm die Möglichkeit, bestimmte Konfigurationen verbindlich und unveränderlich vorzugeben. Das <location>-Element ermöglicht es, bestimmte Konfigurationsabschnitte mit dem Attribut allowOverride="false" als nicht-überschreibbar zu deklarieren.

Listing 2: Unterbinden von Konfigurationsänderungen

<configuration>

   <location path="Anwendung1" allowOverride="false">

      <system.web>

         <identity impersonate="true" userName=" Anwendung1"

            password="password 1"/>

      </system.web>

   </location>

    

   <location path="Anwendung2" allowOverride="false">

      <system.web>

         <identity impersonate="true" userName="Anwedung2"

            password="password2"/>

      </system.web>

   </location>

</configuration>

<system.web>-Konfigurationselemente

Von besonderer Bedeutung für ASP.NET-Anwendungen sind Elemente, die sich innerhalb der <system.web>-Sektion befinden. Die folgende Übersicht beschreibt deren Möglichkeiten und Einsatzbereiche.

Tabelle 2:  <system.web>-Konfigurationselemente

Elemente

Beschreibung

<authentication>

Legt die zu verwendende Authentifizierungsmethode fest. Mögliche Ausprägungen sind: Windows, Forms, Passport oder None (keine Authentifizierung). Siehe Unterkapitel ì  Authentifizierung.

<authorization>

Definition von Zugriffsrechten. Allen Bestandteilen der Anwendung können detaillierte Zugriffsrechte zugewiesen werden.

<browserCaps>

Definieren von unterstützten Browserfähigkeiten. Festlegung ob und wie die Fähigkeiten des Browser erkannt werden sollen.

<clientTarget>

Browsertypen, auf die die Anwendung ausgerichtet ist. Mögliche Ausprägungen sind so genannte Uplevel- und Downlevel-Browser oder eine individuelle Unterstützung für jede Anfrage.

Um ausschließlich Uplevel-Browser zu unterstützen verwendet kann das ClientTarget-Attribut auf "UpLevel" gesetzt werden. Downlevel-Browser werden anschließend nicht mehr berücksichtigt.

<compilation>

Element zur Steuerung der automatischen Kompilierung von ASP.NET-Anwendungen.

<customErrors>

Benutzerdefinierte Fehlerbehandlung. Dadurch lässt sich für bestimmte Fehlersituation ein angepasstes Verhalten implementieren.

<globalization>

Globalisierung und Lokalisierung von Anwendungen für unterschiedliche Kulturkreise.

<httpHandlers>

Definierung der Verarbeitungsmodule für eingehende Anforderungen für unterschiedliche URLs und http-Verben.

<httpModules>

Konfiguration der verwendeten HTTP-Module innerhalb einer Anwendung.

<httpRuntime>

Konfiguration des Verhalten des ASP.NET-Arbeitsprozess

<identity>

Legt die Anwendungsidentität auf dem ausführenden Computer fest.

<machineKey>

Konfiguriert die zu verwendenden Schlüssel für die Ver- und Entschlüsselung von Cookie-Informationen bei Formularauthentifizierung.

<pages>

Vorgabe der seitenspezifischen Konfigurationseinstellungen. Entspricht den Attributen der @Page-Direktive, die auch in jedem einzelnen Webform verwendet werden kann.

<processModel>

Konfiguriert die Einstellungen des ASP.NET-Prozessmodells auf einem Internet Informationsdienst.

<securityPolicy>

Verweist für verschiedene Sicherheitsebenen auf Dateien mit gewünschten Sicherheitsrichtlinien.

<sessionState>

Konfiguration der zu verwendenden Sitzungsstatuseinstellungen für die aktuelle Anwendung.

<trace>

Konfiguration von Listenern für die Anwendungsverfolgung.

<webServices>

Legt die Einstellungen für erstellte XML-Webdienste fest.

 

Hinweis

Nicht alle Standard-Elemente lassen sich auf allen Konfigurationsebenen festlegen bzw. überschreiben. Einige erlauben eine Konfiguration lediglich bis zur Anwendungsebene. Auf Verzeichnisebene stehen nicht alle Konfigurationselemente zur Verfügung. Dadurch ist eine Verwendung des <location>-Element nicht immer möglich. Dies gilt insbesondere für das <authentication>-Element, dieses kann für jede ASP.NET-Anwendung nur einmal und zwar in der Web.config des Wurzelverzeichnisses verwendet werden.

Benutzerdefinierte Konfigurationseinträge

Es ist es auf einfache Weise möglich, beliebige Zeichenketten in der Web.config-Datei abzulegen und aus der Webanwendung heraus abzufragen. Damit bietet sich die Web.config-Datei auch als Speicher für anwendungsspezifische Konfigurationsdaten, z.B. Verbindungszeichenfolgen und Pfade zu Dateien an.

Diese benutzerdefinierten Daten können in Form von Schlüssel-Wert-Paaren in dem <appSettings>-Element abgelegt werden.

<appSettings>

  <add key="Schluessel" value="Wert />

</appSettings>

Das folgende Beispiel verwendet das <appSettings>-Element, um eine Datenbankverbindungs-Zeichenfolge und einige Benutzerinformationen zu hinterlegen.

Listing 3: Benutzerdefinierte Konfigurationen
/Kapitel05/
Konfiguration/Web.config

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <appSettings>

    <!--

        Diese Konfigurationseinträge überschreiben entsprechende Einträge

        in übergeordneten Verzeichnisse, falls vorhanden.

        Beispielkonfigurationseinträge

    -->

    <add key="Autor" value="Bilbo Beutlin" />

    <add key="Hintergrundfarbe" value="#669966" />

    <add key="copyright" value="Alle Rechte vorbehalten (c'2002)" />

    <add key="fileUploadDir" value="FileUploadDir" />

  </appSettings>

</configuration>

 

Um innerhalb einer Anwendung auf diese Werte des <appSettings>-Element zugreifen zu können, existiert die Collection AppSettings innerhalb der Klasse System.Configuration.ConfigurationSettings. Mit dieser Klasse lassen sich alle Werte direkt als String auslesen.

Listing 4:
Lesen von Werten aus der Web.config /Kapitel05/
Konfiguration/Konfiguration1.aspx.vb

' //////////////////////////////////////////////////////////////////////

' /Kapitel05/Konfiguration/Konfiguration1.aspx.vb

' //////////////////////////////////////////////////////////////////////

Public Class Konfiguration1

    Inherits System.Web.UI.Page

  Protected WithEvents WertPaarListe As System.Web.UI.WebControls.ListBox

  Protected WithEvents dsnPubs As System.Web.UI.WebControls.Label

  ' ### Auslesen von Werten aus der

  ' ### <appSettings>-Elemente der Web.config-Datei

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

    Dim AlleSchluessel As System.Collections.Specialized.NameValueCollection

    Dim EinzelnerSchluessel As Object

    Dim SchluesselName As String

    Dim Wert As String

 

    ' --- Lesen eines Wertes

    dsnPubs.Text = System.Configuration.ConfigurationSettings.AppSettings("dsnPubs")

 

    ' --- Lesen aller Werte

    AlleSchluessel = ConfigurationSettings.AppSettings

    For Each EinzelnerSchluessel In AlleSchluessel

      SchluesselName = EinzelnerSchluessel.ToString()

      Wert = ConfigurationSettings.AppSettings(SchluesselName)

      WertPaarListe.Items.Add(SchluesselName & " = " & Wert)

    Next

  End Sub 

End Class

Dieses Beispiel liest im ersten Schritt direkt den Schlüssel "dsnPubs" aus. Dieser beinhaltet die Verbindungszeichenfolge zur Pubs-Beispieldatenbank des Microsoft SQL Server. Im zweiten Schritt werden alle vorhandenen Schlüssel ausgelesen und zu einer Liste hinzugefügt.

Nicht für alle Szenarien bieten Konfigurationsdateien genügend Standard-Elemente an, um alle möglichen Konfigurationsaspekte abzudecken.