I've been spending some time for a while now in Windows Forms land in .NET 2.0 with lots of databinding, taking advantage of (and implementing) things like IBindingList, ITypedList and a few other goodies. However, while trying to figure out how to do something, I did ran into a fairly sad snag.
While trying to accomplish something (see here as to why), I decided to try implementing ICustomTypeDescriptor to present a customized set of properties of some custom objects. The implementation itself runs just fine. However, as many of you probably know, the way ICustomTypeDescriptor is implemented differs in .NET 2.0 than what it used to be in .NET 1.0/1.1.
In the older days, an object had to implement ICustomTypeDescriptor itself to customize how the designer infrastructure interpreted it. While this worked, it was somewhat clunky in that ICustomTypeDescriptor implementations can usually become complex and you had to keep all that complexity inside your object, which probably was already complex for other reasons. Not good.
In .NET 2.0. Microsoft did a great thing and extended the model to support pluggable ICustomTypeDescriptor implementations for types, allowing you to implement it outside of the class being described. You could plug in these implementations either by using the [TypeDescription] attribute (alongside a custom TypeDescriptionProvider implementation), or through the AddProvider() method of the TypeDescriptionProvider class. Good stuff.
But alas, this is where the happy story ends, and the troubles begin. I'm working with a set of third-party Windows Forms controls that as far as I have been able to determine only work with the .NET 1.1 way of doing things (i.e. it doesn't recognize TypeDescriptionProviders). While annoying, I can live with that, and I can even understand why they did it: It would make it easier for them to keep a single code base working for .NET 1.0/1.1/2.0 of their controls (or at least keep them as close as possible).
The Windows Forms team, however, didn't have such constraints. The Data Binding infrastructure in Windows Forms 2.0 (and the BindingSource class, in particular), will barf at you if you try to use it with a type that implements ICustomTypeDescriptor: The designer won't recognize any members of said type, and will gladly trigger exceptions at runtime when it can't find a member it expects to be there. I think, though I haven't dug deep enough to make sure, that they don't support the 2.0-way for custom type descriptors, either, which would suck even more. I'm not the only one feeling the pain, though, several people complained about this but, as usual, it was closed as "By Design" (don't even get me started on that topic).
So, it seems that at this point, I'm left with the choice of either abandoning my ICustomTypeDescriptor implementation (which actually works just as I want to as far as I could test) and abandoning the functionality that gave me (working around this), or maybe try to give up using the BindingSource class altogether and do direct binding, which should require a fairly significant set of changes, as I was taking good advantage of chained BindingSources to make it easier to keep stuff happening. Sigh, definitely not a good day...
