Those of you who were offended by my past two editorials criticizing Linux - and who believe in instant karma - will take particular delight in the story I am about to relate.

On a recent project, I was given the task of creating a feature that would allow for the real-time monitoring of Windows performance counters, similar to the functionality available via the desktop Perfmon tool. After reviewing the .NET Framework SDK documentation, I became convinced that I should use the classes available in the System.Diagnostics namespace, as opposed to those in the System.Management namespace, with which I was already familiar.

Initially, I was rather pleased with the results of my decision. In less than a week, I had built what I took to be a robust implementation on top of what I then perceived as rock-solid and easy-to-use base library classes - most notably the PerformanceCounter class.

The first little burbles I heard back from my QA engineers were all very positive. I was reassured, but oh, how quickly my joy turned to sorrow!

The second batch of comments indicated that some of the counters were returning zero, even when the desktop Perfmon tool indicated that nonzero data was available. I searched my code in vain for errors I might have made in the use of this class.

I greeted the next development with a decided degree of ambivalence. It turned out - according to Microsoft KnowledgeBase Article #324548 (http://support.microsoft.com/) - that invalid counters are a known bug in the PerformanceCounter class! I am told that this bug has been fixed in Whidbey - good work, Microsoft!

Never missing an opportunity to kick me when I'm down, fate dealt me yet another blow. Concurrency testing with my new tool indicated that calls to the NextValue method on PerformanceCounter were blocking each other.

In my case, I was calling this method every five seconds in a Web service application. And so - every five seconds - all users of my application experienced a pause of approximately two seconds while the PerformanceCounter value was retrieved!

Ultimately, I was able to resolve this issue by creating a small database to cache these values. My problem is solved - but it caused me to think:

• Why weren't these little "issues" clearly documented?
• Why no fix plans or workarounds?
• If .NET merely wraps native Win32 APIs, what's the point?

This Issue Is X-Rated...
...because we're focusing on XML this month! (Sorry if you got your hopes up!) Enjoy our usual outstanding coverage with articles covering everything from XML security to the new XML-handling features in Whidbey.

Please send feedback to derek@sys-con.com.