.Net Designer assemblies, C++\C# error

Question

I'm working on an designer-heavy application (using Visual C++ 2.0, but a C# solution should still be relevant). My setup is this:

I have a UserControl named "Host" I'm attempting a UserControl named "Child"

Child contains a property to a class whose type is defined in a different dll entirely, named "mytools.dll"

Child works just fine in the designer. However, when I go to drag "child" onto "host" from the designer, I get the following error:

Failed to create component 'Child'.  The error message follows:  'System.io.filenotfoundexception: could not load file or assembly MyTools, Version XXXXXX, Culture=neutral
.....
{unhelpful callstack}

If I comment out the property in "child" that points to the class in mytools.dll, everything designs just peachy. I have the property marked with "Browsable(false), and DesignerSerializable(hidden), and it does not help.

Is there a way for me to explicitly say "Don't load this dll, you won't need it in design time", or some way for me to force a dll to load from the designer programmatically?

Thanks!

Answer 1

UserControl has a DesignMode property, but I'm not sure if .NET wants to resolve the type beforehand (ie. return null if DesignMode == true).

Alternatively if you're the only developer you could handle the AppDomain.CurrentDomain.AssemblyResolve event and load a dummy assembly yourself.

Answer 2

No, there's a chicken-and-egg problem here. In order to find the attributes you applied, the designer has to use Reflection to load the Type. Loading the type requires any types used by its members to be loaded as well. Which will cause the CLR to go hunting for your mytools.dll assembly.

The probing path in effect at design time is the one for Visual Studio, not your app's. What exactly that path looks like is murky to me. The toolbox plays a role as well. It makes a copy of the assembly that contains the control in a private directory. The place to look is c:\users\yourname\appdata\local\microsoft\visualstudio\9.0\projectassemblies. This often goes wrong and stray copies are left behind in that directory. I have to clean it out by hand from time to time when I notice that toolbox initialization starts to get slow.

Well, something you can check to see if a copy of mytools.dll is present there as well and isn't an old version. Putting it the GAC is one way to stay out of trouble.

Answer 3

If the property is marked 'public' then the UserControl will force the designer to load the external assembly.

You must rework your control to return Object instead of the bad type, and do typecasting if you must keep it public, otherwise, protected should be fine.