Whenever I have to write a large project using CodeDom (and this doesn’t happen as often as you’d think), I almost always find something lacking. It’s as if the whole of CodeDom is half baked.

What’s bugging me the most is that even with the framework’s latest version, 2.0, when Microsoft had the chance to fix things up, they decided, for reasons unknown to anyone outside the company to only implement the new features and fix very few bugs.
Microsoft developers, on their blogs, keep saying that they want not only software to be built with the framework, but also tools. One of the greatest tool-making capabilities they placed in the framework is CodeDom and I’m very appreciative of it, but when such a feature lacks in so many areas, it in several occasions becomes unusable.

What brought this on? Here are the two latest bugs I found and reported:

  1. CodeDom Does Not Allow For Creation of ParamArrays.
  2. CodeDom Does Not Allow For Creation of Finalizers (Destructors).

(Previously, and then some, and then some more, and one more to boot)


3 thoughts on “Half-Baked

  1. The whole of CodeDom feels to me half-baked.

    Let’s forgo the fact that it can’t parse and that compiling using a Dom in-memory writes out temporary files…

    The API is just plain awful. The classes are very simplistic and little more than placeholders for the Compiler to convert to it’s syntax. There is little relationship between the classes and everything is on a lowest-common denominator basis.

    A good example is creating an using a parameter argument… you define the parameter class… then have to create an expression class to reference the parameter. There is no helper and the closest you can get to code re-use is to copy the .name property from one to the other.

    The lowest common denominator restriction shows up with the lack of a switch/case statement. Okay, not all languages support it but those that don’t could simulate something similar with an IF condition surely.

    I was expecting to find an apology for it in .NET Framework Design Guidelines like they did for System.IO but there was nothing.


  2. I’ve got another CodeDom bug for you. I just stumbled over it, while trying to generate code from a DSL using CodeDom: Both the C# and VB code generators do not support the sealed (NotOverridable) keyword on methods. I was trying to create a sealed override from a base class. Both code generators even turn the override into a new virtual method.
    Besides: I really dislike the way MemberAttributes are specified. This should’ve been splitted into seperate properties/enums.

  3. I think I even opened a bug about that once. Can’t remember what with all of the bugs I opened for CodeDom… :/
    re: MemberAttribute: Couldn’t agree more.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s