HowTo: ASP.NET Profile System mit Web Projects nutzen (Visual Studio 2005/2008)

ASP.NET 2.0 führte ein so genanntes “Membership” System ein – darunter sind allgemeine Benutzerregistrier-, Benutzerprofil- und Benutzerrollensystem gebündelt.

Insbesondere das Profilsystem hat mich heute etwas beschäftigt (auch wenn es etwas älter ist). Mit dem Profilsystem kann man einfach Benutzern bestimmte Attribute zuordnen, z.B. Name, Alter, Wohnort oder andere Verweise zu bestimmten Daten innerhalb der Applikation.

Das kann man natürlich auch selber in seiner DB zusammenbasteln – aber das ASP.NET Profile System bietet eine strenge Typsierung, sodass man in der Web.config folgendes anlegen kann:

<profile>
  <properties>
    <add name="PostalCode" />
  </properties>
</profile>

Und im Code hinter so aufrufen kann “Profile.PostalCode” – man kann auch direkt typen angeben, sodass man direkt festlegen kann, welcher Typ eine Profileigenschaft hat:

<?xml version="1.0"?>
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
  <system.web>
    <profile>
      <properties>
        <add name="BirthDate" type="DateTime"/>
        <add name="FavoriteNumber" type="int"/>
        <add name="Comment" type="string"/>
        <add name="FavoriteColor" type="string" defaultValue="Blue"/>
        <add name="FavoriteAlbums" 
             type="System.Collections.Specialized.StringCollection" 
             serializeAs="Xml"/>
      </properties>
    </profile>
  </system.web>
</configuration>

Das ganze wird zudem mit der Membership Datenbank synchronisiert – dort gibt es direkt eine “Profile” Tabelle in dem diese Werte reingeschrieben werden:

image

Das ganze kann man nun noch beliebig erweitern oder eigene Profil-Provider schreiben – hier ein anderer guter Artikel.

Doch wie ruft man denn nun eigentlich die Profileigenschaften ab? Das was auf den MSDN Seiten immer “Profile.[PROPERTY]” verwendet wird, ist schlecht dokumentiert.

Jedenfalls erstellt VS im Hintergrund automatisch eine “ProfileCommon” Klasse die überall erreichbar ist (* hier kommt noch eine Anmerkung!)

So kommt man an die Profile Eigenschaften (System.Web.Profile Namespace):

ProfileCommon profile = HttpContext.Current.Profile
as ProfileCommon;

Danach kann man über “profile.” seine Properties aufrufen.

* – die Anmerkung

Das ganze funktioniert aber nur mit dem “Web Site” Modell (hier z.B. ein Beispiel von Scott) – in Web Applications wird die ProfileCommon nicht automatisch erstellt.
Scott Guthrie schrieb auf einer sehr alten Seite (ganz unten) seine Lösung: WebProfile Generator (Alternative: Die Klasse manuell erstellen)

Problem hier: Das ganze läuft unter Visual Studio 2008 bisher nicht (daher manuell erstellen :( ) – wird aber hoffentlich bald kommen. Auf der Codeplex Seite habe ich bereits einen Kommentar gefunden, kann daher wohl nicht mehr lange dauern.

Anmerkung gernell

Es gibt sicherlich  noch die ein oder andere Möglichkeit auf die Profildaten zuzugreifen, aber extra wegen dieser streng-typisierten und leichten Variante habe ich das einer Eigenentwicklung vorgezogen – schauen wir mal, wann ich dies bereuen werde ;)

 

Wenn dir der Blogpost gefallen hat, dann hinterlasse doch einen Kommentar. Wenn du auf dem Laufenden bleiben willst, abonniere unseren RSS Feed oder folge uns auf Twitter.

About the author

Written by

Hi, ich bin Robert Mühsig und bin Webentwickler und beschäftige mich mit Web-Frameworks auf dem Microsoft Web Stack und scheue mich auch nicht vor Javascript. Der Blog begann als "Problemsammelstelle und Lösungshilfe" und seitdem schreibe ich hier alles auf. Seit 2008 bin ich Microsoft MVP für ASP.NET. Treffen kann man mich online via Twitter (@robert0muehsig) oder hier.

One Response

Comment on this post

Letzte Posts

  • image_thumb.png
    NuGet Package Restore & Build Server wie z.B. AppVeyor

    NuGet ist ja mittlerweile weit verbreitet, aber eine Frage stellt sich natürlich immer noch: Checkt man die NuGet Packages ein oder nicht? In meinem kleinen Side-Projekt, welches auf GitHub liegt und ich über AppVeyor auch bauen lasse nutze ich das Package Restore Feature von NuGet, d.h. in meinem Repository befindet sich kein NuGet Package mehr, […]

  • image.png
    Microsoft Account Login via ASP.NET Identity

    Der Microsoft Account ist die zentrale Identifikationsstelle in der “Consumer-Microsoft-Welt”, allerdings ist das Einbinden eben dieser in die eigene Applikation eher schwierig. Das “Live SDK” ist nun unter dem OneDrive Dev Center zu finden und ganz professionell wurden auch alle Links zum alten Live SDK damit unbrauchbar gemacht. Beim Microsoft Account ist es auch unmöglich […]

  • image.png
    Zeitgesteuerte Azure WebJobs – so einfach kann Azure sein

    Das noch in Entwicklung befindliche Azure WebJob SDK bietet einige coole Features zum Verarbeiten und Bereitstellen von Daten. Bekanntes Beispiel ist das Sample welches auf eine Azure Queue lauscht und sobald ein Item da vorhanden ist anfängt dies zu verarbeiten. Szenario: Zeitgesteuerte Aktivitäten – ohne Queue und co. Mein Szenario war allerdings wesentlich trivialer: Ich […]

  • image.png
    Get Involved in OSS! Ja, aber wie geht das denn mit GitHub?

    Auch im .NET Lager gibt es Bewegung im OSS Bereich und es gibt verschiedene Arten wie man bei einem Open Source Projekt “Contributed”. Was zählt alles zu “Contribution”? Unter “Contribution” läuft eigentlich alles – ob es Fragen/Probleme zu dem Projekt via Issues ist oder Dokumentation nachreicht oder ob man darüber bloggt oder das Projekt vorstellt. […]

  • HowTo: Web.config samt eigener ConfigSection zur Laufzeit ändern

    In dem HowTo geht es darum wie man die Web.config zur Laufzeit ändert und was es dabei zu beachten gilt. Das ganze klappt auch mit komplexeren ConfigSections. Eigene ConfigSection? Vor einer ganzen Weile habe ich mal über das Erstellen einer eigenen ConfigSection geschrieben – im Grunde nutzen wir jetzt fast dieselbe Config. Zur Laufzeit? Startet […]

Amazon Shop

Facebook