Last months MSDN Magazine contains a very interesting article that titles Managing Directory Security Principals in the .NET Framework 3.5. Its a nice introduction to the classes in the new System.DirectoryServices. AccountManagement namespace.
After reading this article, I was both very enthusiastic about it and a bit frustrated at the same time. First of all, I was very pleased with the new API because using the classes in the System.DirectoryServices namespace is painful to say the least. I feel frustrated because its included with .NET 3.5, which is not an option at my current employer for many years to come (yeah, I don't understand this either).
A while ago, I needed to programmatically setup some users in Active Directory with an X509 certificate. There was a lot of friction to accomplish this with the familiar DirectoryServices API. It took me a couple of days to figure it out. Needles to say that this is not documented anywhere. One post on the MSDN forums has put me on right track, but still, it was very hard to figure things out.
There's this book called The .NET Developer's Guide to Directory Services Programming (that I'm currently reading) that provides a lot of tips and tricks. But for the certificate issue, it didn't help either.
Solving this with the new API's is just a breeze and it involves very little code that is easy to read, easy to understand, maintainable and scalable (We all want that, right?).
For the next project I'm going to be working on, again I need to do a fair amount of directory programming. I would like to use the new API as it would probably be more productive and cuts a significant amount of the development efforts. This way I get to focus on solving the real problems at hand instead of wasting my time on low-level API's (same goes for the crappy DAL we are using instead of a decent ORM; this is a whole different story that I'll explain in another post). This means that I want to use the System.DirectoryServices.AccountManagement.dll assembly in a .NET 2.0 application which should be possible because .NET 3.5 is still built on top of CLR 2.0.
As you can see, the AccountManagement API is built on top of the existing DirectoryServices and the DirectoryServices.Protocols API's that are available in .NET 2.0. The Protocols API is a low-level API on top of the Windows LDAP subsystem (wldap32.dll), which ensures that the AccountManagement API has some performance benefits because the ADSI COM interop layer is not used for some scenario's.
Anyway, there are some things that you have to watch out for (there's always a catch: no silver bullets, remember). If the AccountManagement API uses some .NET 3.5 specific feature or extension, you're screwed. Above all, you don't really know until you use a certain feature of the AccountManagement API and it gives you a runtime error. You also need to make sure that Service Pack 1 of .NET 2.0 is installed (you can download it separately). This because there are some additions to the DirectoryServices and the DirectoryServices.Protocols API's. These additions are used by the AccountManagement API.
Again, if you have to do some directory programming, consider using the new AccountManagement API in .NET 3.5. With all this fuss about LINQ, one loses sight on the other great additions to the .NET Framework like this one. The team at Microsoft that delivered these new API's did a really nice job. Kudos!
