The evil designer attribute ;o)

I'm working on a project at the moment where the client want's an "Add-in" for an existing piece of software... it's a COM interop project, .Net 2.0 (and yes, it uses Castle, IoC sits in nicely with the IServiceProvider :) and it hosts a custom designer, and the add-ins must exist in their own directory, outside of the host applications base directory.

At any rate, it's been working just fine so far, but today I was trying to introduce some custom designers... and they weren't being constructed... which highlighted some odd behaviour in the design time support - I have 6 or so assemblies, most are support assemblies, some containing controls and their associated designers, something like this:

public class MyButtonDesigner : ControlDesigner { ..}

[Designer(typeof(MyButtonDesigner))]
public class MyCustomButton : ButtonBase { .. }

And then there is the core assembly which hosts the design surface etc. and contains a number of  COM-visible classes - one of these class in the core assembly is constructed via Com interop by it's Name, and everything starts it's life from there in their Add-in, much like a Main class in a WinForms project.

So the core assembly references the support assemblies, and has no problem creating controls at runtime within these assemblies...

But then...

However, the design time support fails to construct or make use of the custom designers... and doesn't blow up, it just fails silently - personally I hate this kind of behaviour... I like things to fail fast, in your face :)

It appears the custom designer is never constructed because the design time infrastructure fails to locate the assembly it's held within, even though my code has just created an instance of a control from the same said assembly not an instant before... arghh!

To my mind this is madness... I'm not passing a string reference to the type, and the assembly is already loaded, it should be as simple as using the Type in the attribute to create an instance of the designer - looking at the internal implementation of this attribute, I can see where it all goes terribly wrong:

public DesignerAttribute(Type designerType)
{
      this.designerTypeName = designerType.AssemblyQualifiedName;
      this.designerBaseTypeName = typeof(IDesigner).FullName;
}

It's still a puzzle as to why this isn't being resolved... the assembly is already loaded against the current AppDomain - I guess I could mess with the fusion logger to figure it out, there must be some subtle different - but I didn't have the time to waste, so I just cheated, implementing an AppDomain.AssemblyResolve event handler to take care of returning the assembly that's already loaded when matching against a set of pre-loaded assemblies.

I think the silent failure is what annoys me the most, this is something which could be easily introduced and might not be imediately detected when performing a minor update... I'm still not sure how I could write a test to detect it...

Speaking of custom designers... I'm unimpressed by how most custom designers are marked internal... especially for classes that are designed to be subclassed... why the hell is the ButtonBaseDesigner marked internal?