Visual Studio problem with abstract classes in the designer
The problem: you create an abstract class that inherits from something that can be designed in Visual Studio, like Form. Then you inherit another class from this abstract one. And when you get into the Visual Studio designer you see a nice colorful error message: The designer must create an instance of type 'bla bla bla' but it cannot because the type is declared as abstract.
The solution is detailed in a post of Brian Pepin: use the TypeDescriptionProviderAttribute decoration on the abstract class in order to tell .Net (thus to Visual Studio) what concrete type to declare and instantiate should the need arise.
Update: Brian's article is no longer available. I will update the link as soon as possible. Meanwhile, try this article from Microsoft.
Update: I have found the original article somewhere else and relinked it. Also, check out the fourth comment on this entry, where TrevDev links to a Microsoft Connect bug on the TypeDescriptorAttribute which suggests the attribute is not used correctly. That probably explains why people on VS2008 have problems, while the solution works on VS2005.
Now, all you have to do is read the post in question, with one reserve. The blog entry (and some other pages I have found on the net) say that this only works for Whidbey (VS2005), but I am using VS2008 and it worked just as well. However, for a second opinion try this CodeProject article that uses a little conditional compiling trick to switch from abstract classes with abstract methods and properties to normal classes with not implemented classes and methods based on debug/release modes. I kind of dislike the approach, mostly because it needs more effort to implement it, but it could help people that have this problem and maybe use some other IDE other than VS2005 or VS2008.
The solution is detailed in a post of Brian Pepin: use the TypeDescriptionProviderAttribute decoration on the abstract class in order to tell .Net (thus to Visual Studio) what concrete type to declare and instantiate should the need arise.
Update: Brian's article is no longer available. I will update the link as soon as possible. Meanwhile, try this article from Microsoft.
Update: I have found the original article somewhere else and relinked it. Also, check out the fourth comment on this entry, where TrevDev links to a Microsoft Connect bug on the TypeDescriptorAttribute which suggests the attribute is not used correctly. That probably explains why people on VS2008 have problems, while the solution works on VS2005.
Now, all you have to do is read the post in question, with one reserve. The blog entry (and some other pages I have found on the net) say that this only works for Whidbey (VS2005), but I am using VS2008 and it worked just as well. However, for a second opinion try this CodeProject article that uses a little conditional compiling trick to switch from abstract classes with abstract methods and properties to normal classes with not implemented classes and methods based on debug/release modes. I kind of dislike the approach, mostly because it needs more effort to implement it, but it could help people that have this problem and maybe use some other IDE other than VS2005 or VS2008.
Comments
What a bummer. That probably explains why some people make it work and some can't. I found Brian's article and relinked it, together with your own link. Thank you!
SideriteWhile following up on the helpful suggestions in your article (thanks!) I discovered this Microsoft link that indicates that the TypeDescriptionProviderAttribute technique does not yet work correctly: http://connect.microsoft.com/VisualStudio/feedback/details/492729/typedescriptionproviderattribute-does-not-appear-to-be-recognized-on-an-abstract-generic-form
TrevDevThank you for pointing out the broken link. I also looked for his article and found nothing. I did however contact Brian and requested the content, so maybe all is not lost. I am updating the post with the information from Microsoft which, although pretty complete, has the problem of not being very clear.
SideriteThe link to Brian's article is broken, do you know where another copy can be found?
Thanks