CLR & OS Independence

A storm brews on the distant horizon around the delivery of Longhorn and the Future Of of Assembly Versioning. Rocky Lhotka and Kent Tegels feel the versioning strategy coming down the road will stagnate Microsoft’s version of the .NET runtime. I wasn’t too alarmed by the article on the ServerSide.NET for a few reasons.

First, to some extent, development life on Windows has followed this course and thrived for sometime. The Win32 API has been the foundation of the platform and changes come relatively slowly with major OS releases and service packs. On top of the API assorted runtimes and frameworks (like MFC and the VB runtime) made developers more productive by encapsulating and enhancing the platform. These platforms could provide some amount of innovation, but major revolutions were almost impossible without support from new features in the underlying platform. It’s not always a bad thing to say the foundation is stagnant, though. After all, I wouldn’t feel comfortable if System.Object were sprouting new methods every year.

Secondly, I know what you might be saying: “Just because it’s always been that way doesn’t mean we can’t have a better solution”. Yes, this is true. In fact, the above approach is the approach in theory only. In practice, changes come as needed and when the demand is present. Remember the NT 4 Option Pack? The option pack shoehorned a distributed application platform (IIS, message queuing, transaction server) into a one year old operating system while Windows 2000 was still cooking in the oven. How about the foundational pillar of Longhorn known as Avalon that suddenly appeared on XP machines around the world?

Finally, wherever Microsoft stagnates, competition finds a niche. Just look at Firefox and search tools over the last 12 months. Competition forces Microsoft into innovation – and they always find a way to stay competitive. The competition in the common language runtime arena is here already. I'm not worried yet.