This new namespace, as I see it, is just provided as a friendlier way to query an LDAP server and is actually built on top of the plain DirectoryServices bits. And it shows... For example you have to dispose all objects performing a search (FindIdentity) or as Gary Caldwell puts it:
This call has an unmanaged memory leak because the underlying implemenation uses DirectorySearcher and SearchResultsCollection but does not call dispose on the SearchResultsCollection as the document describes.
Also, because AccountManagement is not as close to the metal as DirectoryServices you can only control whatever Microsoft chose to expose in the API.
However a fantastic feature of AccountManagement is the ability to fall back on a DirectoryServices object whenever you need to because the underlying object of any Principal is exposed through GetUnderlyingObject().
With that much power in our hands we can now use this to set some properties unexposed by AccountManagement. Here's a generic method I made to set LDAP properties on any Principal (users, groups, computers):
Use it like this:
Being user-friendly while keeping control? I'm starting to like that little guy.
UPDATE: As an anonymous commenter pointed out, there's a way to actually map an AD attribute to a property of a class inheriting UserPrincipal. The technique consists of decorating the property with the attribute DirectoryProperty and the field name as parameter (as seen here).
NOTE: code indentation is messy in the examples. I need to fix something in my snippet tool.
I found good resources of c#. Check this out
ReplyDeletehttp://csharptalk.com
Please see figure 13 on http://msdn.microsoft.com/en-us/magazine/cc135979.aspx. This is the correct way of doing this.
ReplyDeleteI was not aware of those attribute-based extensible metadata.
ReplyDeleteThough I would use it only for standard attributes not for custom ones because hard coded attributes could change in the ActiveDirectory.
I'll update this post and quote you anonymously ;)