To work around the memory leaking issues in the .NET classes is in theory quite simple, do not use those classes. That is the starting point we had. Instead what we want to do is, by minimizing the affection on all our projects, rebuild our AD classes to use a beter way to communicate with the Active Directory.
In .NET 2.0 the System.DirectoryServices.Protocols was introduced, which is a collection of general classes to communicate with practically any directory over LDAP. Unlike System.DirectoryServices which builds on ADSI, the System.DirectoryServices.Protocols builds on the newer and better wldap32.dll.
Heres an overview of the different namespaces and what teqniques they rely on, taken from Introduction to System.DirectoryServices.Protocols.
In .NET 3.5 yet another namespace arrived, namely System.DirectoryServices.AccountManagement. This is excactly as it sounds a set of classes for account management. In theory this is exactly what we need. The classes are very easy to use and you do not have to do any LDAP programming at all.
Unfortunately there are some direct disadvantages with System.DirectoryServices.AccountManagement. The classes build on a mix of System.DirectoryServices and System.DirectoryServices.Protocols, which means that we will still be stuck with the memory leak that we are trying to get away from. Another issue is performance, which is not really a problem when a user is changing the password, but is a big problem when making large searches.
In .NET 2.0 the System.DirectoryServices.Protocols was introduced, which is a collection of general classes to communicate with practically any directory over LDAP. Unlike System.DirectoryServices which builds on ADSI, the System.DirectoryServices.Protocols builds on the newer and better wldap32.dll.
Heres an overview of the different namespaces and what teqniques they rely on, taken from Introduction to System.DirectoryServices.Protocols.
In .NET 3.5 yet another namespace arrived, namely System.DirectoryServices.AccountManagement. This is excactly as it sounds a set of classes for account management. In theory this is exactly what we need. The classes are very easy to use and you do not have to do any LDAP programming at all.
Unfortunately there are some direct disadvantages with System.DirectoryServices.AccountManagement. The classes build on a mix of System.DirectoryServices and System.DirectoryServices.Protocols, which means that we will still be stuck with the memory leak that we are trying to get away from. Another issue is performance, which is not really a problem when a user is changing the password, but is a big problem when making large searches.
Comments
Post a Comment