IHttpHandler and IHttpModule Slide Deck

Gyro 1.0 Released!

Don Syme just posted a note to the Rotor mailing list:

Gyro 1.0 is now available for download at http://research.microsoft.com/research/downloads. The Gyro community website is at http://gyro.sscli.net, and Microsoft Research's web page for generics is at http://research.microsoft.com/projects/clrgen.

Good news for everyone that wants to try out C# generics before, say, October...

Tracker Offsets

Just got an email from LongSkate. Someone's getting tracker offset racing trucks, nah, nah, nah....

Should look something like this, but powdercoated red.

Well, that didn't take long...

EventLogReader

Recently I needed a class that consumed information from the Event Log. I'm a big fan of XmlReader, so I crufted up EventLogReader, which uses the same cursor-centric model found in XmlReader. Client code that uses EventLogReader looks something like:

string log = "Application";
string machine = "laguna";
string source = "EAPOL";

EventLogReader reader = new EventLogReader(log, machine, source);
while(reader.Read())
{
	Console.WriteLine("{0} {1}, {2}",
		reader.TimeGenerated.ToShortDateString(),
		reader.TimeGenerated.ToShortTimeString(),
		reader.Message);
}

As you iterate over the event log entries, EventLogReader exposes properties (just like EventLogItem) for each item in the log.

A zip that contains the library source is available - I'll post some sample code that uses the library in the next couple of days. Right now the only code that uses the library is a framework for new ASP.NET endpoint types that I built using IHttpHandler, and it tends to obscure the EventLogReader.

The library passes FxCop except for warnings about strong naming and complaints about returning arrays from properties. Feel free to add a strong name yourself, since you have the source - I'd rather not give out my real keys; the array issue is because I'm just surfacing the return value from the EventLogItem type. Also, in this release code coverage is moderate - I'll build up some unit tests shortly, but it works for my demos and my debugging pages - YMMV. Bugs, complaints, etc. to mickey at servergeek dot com.

CLS Compilance

Brad posted about component vendors that aren't CLS compliant...

When I see a commercial component that fails to meet even the most basic levels of standard community behavior, I immediately think about problems I can't see. If a vendor doesn't understand the importance of CLS compliance (a very low bar to hurdle in my opinion), what other mistakes in judgement have they made? Lack of CLS is visible. Mishandling the Dispose pattern is not. Do they take the time to perf-test the component? How serious are they about other (more difficult) standards, if they can't manage the simplest? Do they use FxCop? Doubtful, since FxCop complains about CLS compliance.

What do I look for in a component?

• Support Your component probably has bugs. I know it. You know it. So let me in on the secret - after all, I did pay you for your component, so you should at least let me know where the sharp edges are. Tell me about your bugs, so I don't spend my time debugging issues you already know about. And a workaround would be nice. I once had a product held up for weeks while we ripped out a lame-ass ActiveX control with a memory leak. We paid several hundred dollars for the control, and were screwed by a bug that was well-known to the vendor. If we had known about the bug, my team would have avoided a few weeks working 100+ hours/week due to a faulty component.
• Transparency I want components that show everything. Test plans. code coverage results. Work-arounds for known problems. You have (or should have) these things already, I'm just asking you to share.
• Standards Don't sell me a web component that spews out tag soup. Don't sell me a .NET component that only works with C# or VB. Don't sell me a custom web control that only works with IE or Mozilla.

Do these things, and I'll buy your component. Don't do them, and I'll mock you for years into the future.