Scott Hanselman's article on "The Myth of .NET Purity" (articlenews.cfm?id=356) struck a chord (with even .NETDJ editor-in-chief Derek Ferguson jumping into the discussion).

Why the Myth Exists at All...
I think this article is right on, but felt that we should confront the issue of why this kind of rebuttal is needed (and it is needed). We find people who are earnest only in so far as they can justify their existence. Therefore they brand something heresy as soon as they abandon the practice themselves. Let's assume that COM interop was a horrible waste of resources; it still wouldn't justify discarding in such a wholesale manner a tool and the wealth of existing functionality the last generation always holds. I have heard people in ASP circles a while back declare that "session state is bad." Like hybrid applications, session state in ASP is a tool; use it or don't use it, but if you happen to need a hammer it doesn't make the saw evil.
Posted by Patrick Hynds on Jul 17 @ 10:16 PM

But "Wrapping" Can Still Get Out of Hand!
I would never suggest that COM Interop should be gotten rid of or is in any way, shape, or form "evil." However, as a developer who spends more than 90% of my coding time working with the System.DirectoryServices and System.Management namespaces, let me tell you - MS could have saved developers a lot of grief by having written some managed protocol handlers here, rather than just wrapping up the old, troubled APIs.

As one example of this, the DirectoryEntry class in System.DirectoryServices allows you to pass a username and password to its constructor. However, when you use the WinNT ADSI provider, these parameters are sometimes ignored. Why is this? Because of a limitation in the existing APIs that were wrapped!

Similar problems abound in the System.Management namespace - where I recently managed to prove that Impersonation (a native API) interacts differently with EnablePrivileges (a wrapped API) under ASP.NET than it does under the Console. In working through this with MS, I have been passed around to 10 different people in their support infrastructure. Why? Because the old, obscure APIs that have been wrapped are a "dark art" known only to a few individuals within the Redmond infrastructure.

Once again: it would've been better to have recreated the whole thing in C#.
Posted by Derek Ferguson on Jul 18 @ 10:12 AM

Practicality Is What Matters Most
There is a lot to be said for purity for purity's sake? I have never subscribed to this type of thinking. At the end of the day we all want to build dependable software that solves the business problem at hand. Everything should always be taken in the context of a solution with a sense of practicality. I think most of the software development community has this maturity.
Posted by Dean Guida on Jul 25 @ 04:00 PM

Your Comments on system.directory Are Interesting
Your comments on system.directory are interesting. ADSI is simply a com wrapper, so technically it's a "wrapped wrapper" of the native LDAP API, which of course is C++ only. That being said, the directory entry class you are referring to is a "wrapped, wrapped wrapper." Ultimately, the big disappointment of the .NET Framework 1.1 and the hope for 2.0 is more native framework classes.
Posted by Tim Huckaby on Jul 25 @ 07:07 PM

Send us your feedback. Letters may be edited for length and clarity. Please provide full name, location, and, if applicable, title and company.