One of the things I did in my latest version of WSS RSS was add a configuration file. I didn’t just use web.config since WSS has a tendency to overwrite it when you upgrade a new virtual server to support WSS. However, I didn’t go the usual route of parsing the XML configuration information into objects via serialization or some other mechanism. Instead, I just loaded up an XmlDocument and queried it with XPath whenever I need to read configuration information. I do this multiple times per web request (once per web and list in the feed).

This leads me to my point – I’m beginning to think the whole idea of XML serialization is off base. Given an object graph, I can serialize it into XML and then deserialize it into an identical object graph. However, I don’t think I can take an arbitrary XML document and always be able to deserialize it into an object graph. XML concepts like derivation by restriction are difficult to model in a strongly typed object model like CLR’s. And since I have XPath, I don’t think I want to always deserialize my XML into objects – it was much simpler to execute XPath queries than it would have been to manually traverse the object graph or build my own query mechanism.

Picked up The Matrix Reloaded Soundtrack today. Haven’t given it a full listen, but it’s 2 CD’s and so far I like what I hear. Also includes the Animatrix trailer, Final Flight of Osiris trailer, the Superbowl trailer and a documentary on the making of Enter the Matrix. Day job stuff tomorrow means I wont be able to see the movie until Friday. So what will that make me, the last Microsoft employee in Redmond to see it?

To answer your question though, I am building WebService support into the [bug tracking] system.
[Jesse Ezell Blog]

Great! Looking forward to seeing the code or the app (depending on what you release)

I definately agree with Scott to a point. In the end, you can’t have pure .NET, because even the APIs themselves are going to call COM objects. So, if .NET can do it, why not my app? Well, for one, I want my apps to work under Mono and any other runtimes that come out. Not a big deal today, but planning ahead is a good thing.
[Jesse Ezell’s Weblog]

To me, the biggest reason to write 100% managed code is the obvious one – less work. CLR and BCL do much more heavy lifting than COM or Win32. What better reason do you need?

.NET APIs not only call to COM objects but also into the Win32 API as well. When you call System.IO.File.Open(), eventually that ends up as a call to CreateFile(). In Rotor, File.Open results in the construction of a FileStream object. You can see the call to CreateFile in the internal FileStream constructor (sscliclrsrcbclsystemiofilestream.cs). Reflector reveals a similar implementation for the .NET Framework. But as we start to see other CLR implementations on other platforms, I start to wonder how many of the underlying platform unmanaged API’s will be consistent across platforms? Some will obviously be consistent – file access, memory management, network sockets to name a few. Others such as distributed transaction management or 3D rendering will be missing or implemented in a inconsistent manner. For example: it would be very difficult to build a generic 3D library that used DirectX or OpenGL under the hood. You’d probably wind up with a library that targets the lowest common denominator, leaving vast portions of both APIs unexposed. Developers using your 3D library would be able to target both environments, but at a stiff price – lack of access to the cutting edge features of either environment.

Here’s a question I pose to blogspace: Is the .NET Framework a platform or just better plumbing for the underlying platform?