I'm sure many people are familiar with the principles of object-oriented programming such as inheritance, polymorphism, etc. However, not everybody may have considered is the potential for creating a class hierarchy of forms and dialogs. It can be very beneficial to have the ability to extend an existing form class to create a more specific type of form. For example, I constructed a group of C# forms and controls that allow me to design a page as a control and place it in either a wizard or a property sheet. I can just extend my custom page from the base page type and drop on whatever controls I need for that particular page. That's something that I think should have been in the .NET framework, but that's another story.
In any given class hierarchy, it's probable that at least some of those classes will exist purely for the purpose of polymorphism, and they'll be abstract classes. This is no less true with a hierarchy of forms or controls. In my particular example, there's not much use in instantiating an instance of the base page class because it'll have no controls on it, so I marked it as abstract. As I soon found out, the designer in Visual Studio 2005 takes great exception to this.
For some reason, the VS2005 designer tries to actually create instances of these abstract base classes and I'm not quite sure why. If all the abstract methods and properties in the base classes are made virtual and given simple, default bodies, so that the classes can be instantiated, the designer will start working again. It's a real shame; I love using abstract methods in base classes because I find myself often forgetting to implement the derived-class versions of virtual methods like I'm supposed to, and it's nice to have the compiler remind you if you don't. It's just unfortunate that this can't happen if you want the designer to work with your abstract forms or controls.