Monthly Archives: May 2005

Posts per Month

I’ve posted quite a bit this month with a fairly reasonable mix of technical and non technical posts. I decided to plot my posting habits since I started my blog. There was a definate upwards trend at the tail end last year with a spike over January, I wonder what events in my life change my posting rate.


Product Feedback Center is broken!

No, not the site – some of the responses. Darren posted up this one worder which pointed to an issue he raised with IBF and VS.NET 2003 on the Product Feedback Center site which is part of the MSDN lab. After five days of back and forth between the guys at Microsoft it was resolved as Not Reproduced.

Now – what annoys me isn’t the fact that the guys couldn’t investigate and fix the issue, its the fact they they didn’t forward this piece of feedback from an MVP and one of the few people who know about IBF (on the planet) to the Microsoft Office team  to address.

Web applications are potential information silos.

I read this post by Evan Williams a while back and put it into my task list to reply. Running an organisation via public web applications is a possibility today, but there is cause for concern with taking this approach. Firstly, each web application represents an information silo and it can be hard to create linkages across these stores.

Technologies like RSS do address some of the problems but RSS feeds tend to be transient and don’t make for good programmatic query interfaces. I think applications like Outlook and JetBrains’ Omea Reader are going to start playing a much larger role for organisations that work with information stores like this, but they can only do it if the various web application vendors start exposing API’s for doing things like fetching bug lists (FogBugz might already do this – I don’t know).



I was reading this post by Ted Neward and it got me thinking. While I agree that being able to parse code would be really useful (all issues with that aside) there is something that I would like to see before that which is a higher level abstraction over the top of CodeDom.

As an example, lets say we wanted to define an exception using CodeDom. Today we would have to whip up a CodeCompileUnit, build a CodeNamespace, add a CodeTypeDeclaration and populate it. If we wanted to support serialization or any custom properties we would need to go ever further.

Rather than having to do this it would be cool to be able to use higher level abstractions. To quickly demonstrate the idea I created this lump of sample code.


Basically its just a CodeException class which is specifically designed for emitting an exception. You just assign the CodeNamespace to its Namespace property and when you generate the CodeCompileUnit that its nested in it slurps in the exception code. When this code is run it will emit the code to the console.


Now – building an exception is pretty trivial, even with the current CodeDom, but imagine what you could do if you dug through all the patterns material out there and build CodeDom abstractions for them? The implementation would be fairly important.

You wouldn’t want to just embed an abstraction into a CodeCompileUnit since an abstraction could easily span assemblies, thats why I took the approach of wiring up to the PopulateTypes event on the CodeNamespace. That way if you had an abstraction that represented a pattern you could just hand it the CodeObject that it needed to emit against and the code would just end up in the right location.


Food for thought.

Code Camp Oz Downloadables

Do you like downloadables? I like downloadables! Get your downloadables for Code Camp Oz here. Currently just my material is there but I expect other material to be coming online shortly. Sorry this has taken so long to get out – we’ve been catching up on sleep

P.S. Thanks to Darren Neimke for offering us a permanant home on Project Distributor for the code. Probably something the other Code Camps from around the globe should consider too!