.NET Directory Services Programming Landscape

Now that we know a little bit about directory services and LDAP, it is time to discuss how we access these services from the .NET Framework. The inaugural release of .NET version 1.0 included a namespace called (appropriately enough) System.DirectoryServices. This namespace was packaged in its own assembly, System.DirectoryServices.dll. Throughout this book, we'll refer to System.DirectoryServices as SDS.

The next major .NET release (version 1.1) saw no major changes to SDS, with only a few bug fixes and no major new features. However, .NET 2.0 introduces two important new capabilities for directory services programming. System.DirectoryServices.ActiveDirectory (SDS.AD) is a brand-new namespace included in the existing System.DirectoryServices.dll assembly that adds significant new capabilities specifically for accessing Active Directory and Active Directory/Application Mode (ADAM). It builds on top of the general API provided by SDS and integrates tightly with it. Additionally, it wraps a few of the native Windows Ds* API calls for Active Directory- and ADAM-specific operations.

System.DirectoryServices.Protocols (SDS.P) is also new in .NET 2.0 and is a complete departure from SDS. It provides a lowerlevel API for LDAP-only programming. It can speak LDAP via the native LDAP TCP/IP protocol or via the Directory Services Markup Language (DSML) protocol, which uses XML, SOAP, and HTTP to encapsulate LDAP messages. SDS.P is packaged in its own assembly, System.DirectoryServices.Protocols.dll, and it does not rely on any SDS or ADSI features. SDS.P provides the highest level of control and performance for managed LDAP programming at the expense of being more complex than SDS.

Since SDS.P provides a completely different API for .NET directory services programming, .NET developers now have a choice of which API to use. We'll discuss when to use which interface later in this chapter, and we'll even use SDS.P in a few examples in later chapters. Unfortunately, complete coverage of SDS.P is beyond the scope of this book. You smart SDS.P developers will have to translate most of the examples yourselves!

For those of us still using .NET 1.1 or (gasp!) 1.0, the decision about which API to use is much easier to make given we do not really have an option (we can only use SDS). We understand that many of us will need to go back and forth between all versions of the platform for at least a few more years. This book attempts to bridge the gap between .NET 1.x and 2.0. We will try to show how to do things both ways when version 2.0 provides something significantly new and different.

A variety of other dark horse contestants are in the .NET directory services landscape as well. Windows Management Instrumentation (WMI), the ubiquitous API that is very popular in the systems scripting world and seems to provide wrappers for just about everything in Windows, provides some directory service features. A few third-party providers also have some interesting .NET APIs that we can use. Finally, Microsoft is building a brand-new scriptable command shell code-named "Monad" that is based on .NET-managed code and provides some directory service features. Sadly, we are going to ignore all of these for the rest of the book, as we don't think that they are as interesting to our primary audience, the .NET enterprise developer, and we already have plenty to cover without them.

Native Directory Services Programming Landscape