A long time ago I posted an article explaining why Visual Studio can’t design abstract forms. I also promised that I’d show you a way you could make it work in Whidbey using Whidbey’s type description provider mechanism. Well, a long time has passed and I never wrote the follow-up. It’s time I fulfill my promise.

Note: While this is a cool and funky example of the power you wield with custom type description providers, Microsoft doesn't support abstract base classes in the designer, so if you use this technique in your own code, you are on your own.

System.Design is an assembly that contains design-time classes such as ControlDesigner. The System assembly also contains a System.ComponentModel.Design namespace that contains design time classes. Even System.Windows.Forms contains a System.Windows.Forms.Design namespace. Was Microsoft just incredibly lazy here, randomly spreading classes wherever was convenient, or was there an actual purpose to this madness? And, if there was a purpose, what should you consider when writing your own controls with their own design time logic?

When I came back from vacation all hell had broken loose. You see, a few days before I came back, Microsoft decided that WinFX, or at least the bits that remained after the latest round of Longhorn cuts, would also be supported on downlevel platforms. To a guy deeply entrenched in the development of Windows Forms, this is fairly impactful news as a key part of WinFX is Avalon.

Not that the news wasn’t welcome. I’d been lobbying the powers that be for months that this is the right thing for customers. People buy Windows because of the apps they can run on Windows. Developers write apps for Windows because it is the most pervasive platform so they get the broadest reach. Producing a brand-new API and only exposing it on a version of Windows that no one has does not encourage developers to spend valuable time writing apps for it, especially if they can write to an existing API and support both the old and new operating systems.

Imagine this: you have a great software project you’re working on. You’ve decided to use Visual Studio’s Visual Inheritance feature so you can re-use portions of your application’s UI. While working on the base classes, you decide that all base forms need to provide a “Title” property, so you add the property and make it abstract. You go on for a little while longer and then open a designer for a form that derives from your base form. What do you get? A nice fat juicy error message stating that abstract classes cannot be designed.