Bei der Entwicklung von ASP.NET-Webs soll es schon hin und wieder vorgekommen sein, daß gewisse eMail-Funktionalitäten implementiert werden mussten. So ist wohl hinlänglich bekannt, daß man in der web.config an zentraler Stelle den dafür notwendigen SMTP-Server konfigurieren kann:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="Network" from="admin@meinewebsite.de">
      <network host="smtp.meinewebsite.de" port="25"/>
    </smtp>
  </mailSettings>
</system.net>

Das Testen gestaltet sich in der Entwicklungsumgebung (Visual Studio und Cassini-Web-Server) aber etwas schwieriger, denn kaum ein Provider läßt es zu, daß von außen eMails in den SMTP-Server gekippt werden. Spam sei Dank...

Der einzig gangbare Weg scheint der über den in den diversen Windows-Version integrierte IIS zu sein, den man dann zum Debuggen verwenden muss. Aber ... es geht ein wenig einfacher, wenn man sich die Attribute des smtp-Tags in der web.config mal ein wenig genauer ansieht. Dort gibt es für das deliveryMethod-Attribut den Wert SpecifiedPickupDirectory.

Für einen Response-Filter, der den HTML-Code vor der Ausgabe noch einmal gezielt verändern kann, habe ich eine Lösung gesucht, die dafür notwendigen Informationen zentral abzulegen. Nahe liegend ist da natürlich die Verwendung der ASP.NET-eigenen web.config. In diesem Fall genügten mir aber die einfachen Key/Value-Paarungen des Abschnittes AppSettings nicht, da ich mindestens 4 Konfigurationswerte unterbringen wollte, und dies auch noch mehrfach:

• pageName
• findString
• newString
• type

Die Lösung liegt in der Verwendung der Klasse ConfigurationSection, mit der man relativ einfach eigene Konfigurationsabschnittstypen implementieren kann. In einer Klasse, die von ConfigurationSection ableitet, werden im Grunde die einzelnen Eigenschaften (Properties) definiert, die später in der web.config konfigurierbar sind und per Code über den ConfigurationManager abrufbar werden.

Die meisten ASP.NET-Webs haben irgendwo einen Bereich, der nur bestimmten Benutzern zugänglich sein soll und somit eine Anmeldung (Login) erforderlich machen. Zu diesem Zweck stellt Microsoft in seinen ASP.NET-Entwicklungsumgebungen eigene Steuerelemente bereit, die sich mit wenigen Mausklicks in die Web-Seiten integrieren lassen und dem Entwickler eine Menge Arbeit abnehmen...

Basis dieser Steuerelemente sind sog. Provider, die die Daten für die Benutzerverwaltung bereitstellen. Aktuell braucht man für den kompletten Satz an Features folgende drei Provider:

1. Membership-Provider (Mitgliedschaft, d.h. Benutzerdaten)
2. Role-Provider (Rollen)
3. Profile-Provider (Profildaten, d.h. weitergehende Benutzerdaten)

Hinter diesen Providern, die in der web.config konfiguriert werden, steht eigentlich immer eine Datenbank, die allerdings entsprechend vorbereitet werden muss. Setzt man z.B. im Hintergrund einen Microsoft SQL-Server 2000 ein, so braucht man in der Datenbank, die als Provider-Datenquelle eingesetzt werden soll, eine ganze Reihe Tabellen, Stored Procedures et cetera.

Auch hierbei hat Microsoft den Entwickler nicht alleingelassen: im Ordner \Microsoft.NET\Framework\ gibt es das Tool aspnet_regsql.exe, mit dem man entweder über die Kommandozeile oder ganz bequem per Dialog eine Datenbank in einem Rutsch mit allen erforderlichen Objekte bestücken kann.

So weit so gut ? aber was soll man tun, wenn man keinen Zugriff auf die Oberfläche des Webservers hat, auf dem das Projekt später gehostet wird, um das Tool auszuführen? Die wenigsten Provider erlauben einen Remote-Zugriff?