Der Namespace System.Web.Profile beinhaltet wahrlich nicht viele Klassen, aber trotzdem kann er einen auf die Palme treiben - wenn man nämlich versucht herauszufinden, wie man ein blödes Benutzerprofil zu Fuß auslesen kann, und es ums Verrecken nicht findet.
Letztendlich hat sich die Hartnäckigkeit aber ausgezahlt. Die Zu verwendende Klasse lautet ProfileBase:
ProfileBase pb = ProfileBase.Create("UsernameXYZ");
Im Anschluss kann man über pb respektive die statischen Eigenschaften und Methoden von ProfileBase an die Eigenschaften kommen.
Zum Hintergrund: ich habe mir ein Custom Control gebaut, welches mir anhand einer vordefinierten Liste von Eigenschaften die entsprechenden Profil-Werte eines Benutzers ausgibt. Der grobe Vorteil liegt darin, dass man das Control einfach in die Anwendung ziehen kann, und keine Zeile Code mehr schreiben muss, es wird alles vom Control und einem beliebigen Profil-Provider erledigt.
Der Designer sieht also nur noch das hier:
<%@ Register Assembly="69Grad.Forum.Controls" Namespace="NeunundsechzigGrad.Forum.Controls"
TagPrefix="cc1" %>
Und kann die entsprechenden Profil-Eigenschaften ohne Code in der Seite platzieren:
E-Mail-Adresse: <cc1:UserProfile ID="UserProfile1" ShowGroup="ForumUser" ShowAttribute="Email" runat="server" />
Damit alles schön benutzerfreundlich bleibt, sind ShowGroup und ShowAttribute Enumerationen. Das hilft vor allem dabei, Fehler und langes Rumprobieren durch falsche (String-) Eingaben zu verhindern:
public enum ProfileAttribute
{
Email,
Username,
Registered,
LastLogin
}
public enum ProfileGroup
{
ForumUser
}
Das CustomControl selbst ist relativ simpel, es holt sich in CreateChildControls() die ID des anzuzeigenden Benutzers (etwa via QueryString oder über eine Property), holt sich anhand derer via MembershipProvider den Benutzer, und schaut dann nach, ob in den in der Web.Config hinterlegten Profileigenschaften die dabei ist, die via "ShowAttribute" (was dem Enum ProfileAttribute entspricht) angegeben wurde. Ist dem so, rendert es den Wert der Eigenschaft als Literal bzw. fügt es der Control-Collection hinzu.
MembershipUser user = Membership.GetUser(UserID);
ProfileBase pb = ProfileBase.Create(user.UserName);
if (ProfileBase.Properties[propertyName] != null)
{
Literal attributeOutput = new Literal();
attributeOutput.Text = pb.GetPropertyValue(propertyName).ToString();
Controls.Add(attributeOutput);
}
Als knackig und weiteren kleinen Zeit-Killer hat sich hier übrigens noch die Verwendung von Gruppen bei der Definition der Profil-Eigenschaften in der Web.Config erwiesen:
<properties>
<group name="ForumUser">
<add name="Username" type="System.String" provider="ForumProfile" />
<add name="Email" type="System.String" provider="ForumProfile" />
<add name="Username" type="System.String" provider="ForumProfile" />
<add name="Registered" type="System.DateTime" provider="ForumProfile" />
<add name="LastLogin" type="System.DateTime" provider="ForumProfile" />
</group>
</properties>
Denn: "Username" entspricht nicht "ForumUser.Username". Die Suche in den Properties (if (ProfileBase.Properties[propertyName] != null) ...) kann also nicht klappen. Deshalb gibt es für das CustomControl noch die Eigenschaft ShowGroup.
Ich setze dann vor der Abfrage auf die Properties-Collection das Ganze noch zusammen:
string propertyName = ShowAttribute.ToString();
if (ShowGroup != null)
propertyName = ShowGroup.ToString() + "." + propertyName;
Damit ist dann der Zugriff auf die richtige Profil-Eigenschaft möglich. *
* Natürlich muss man, wenn man schön faul und automatisiert im Profile-Provider die Eigenschaften via Reflection gegen ein eigenes User-Objekt feuert den Gruppennamen wieder entfernen, denn "Username" entspricht auch hier nicht "ForumUser.Username". Aber das ist eine andere Geschichte ...
