Hi
Then I've two problems:
1. I can't share types between appdomains without having their
assemblies loaded in the appdomain as well.
2. I can't share windows.forms user controls over appdomain boundaries
(therefore I need at least the windows.forms designer in the main
appdomain ... because of problem 1 I couldn't test what happens if I try
to put a 'remote' control into the forms designer ... but I suppose that
this fails like remoting any other windows forms control :/)
My current solution for the problem is as follows:
Overwriting the AssemblyResolve event in the appdomain and >hard core<
loading the assemblies from the disc using a byte[] array (with this
trick I get around the locking problem).
But with this dirty hack I've another problem: a memory leak :/ but
currently I can't see an solution for getting around this problem. I've
dissassembled the TypeDesigner from Microsoft.VisualStudio.dll (which is
delivered with the framework, not with the IDE). And there its a
toolbox manager which does almost the same as I do as far as I can tell
except they don't load the assembly with the byte hack instead they're
copying it to a temporary location (Somewhere in the users appdata
folder) and there they load it with Assembly.LoadFile (LoadFile does
load assemblies twice, if needed LoadFrom doesn't do this it first looks
into the current appdomain).
Am I right that VS.NET has a memory leak ? And it allocates a few bytes
every time an assembly with an user control is recompiled ?
but nevertheless the AppDomain load/unload workaround would be nice if
it would work but I can't see to prevent the automatic assembly load, if
I transfer types and the unability to share controls between
appdomains in the same process is really a hard problem for C# users.
But maybe I'm completly wrong or I haven't seen another solution ?
Regards
Mike
You'll need to have both your designer and your control in a separate
domain. Then when-ever you need to refresh the control, you'll need to tear
down that domain and create a new one.
