assembly loading problem

  • Thread starter Thread starter Mike Krueger
  • Start date Start date
M

Mike Krueger

Hi

I'm currently working on a forms designer for a free .NET IDE
(SharpDevelop -> www.icsharpcode.net/OpenSource/SD).

problem:
I try to put 'custom' components (user controls from the current open
project) into the forms designer. The project must be compiled for
making this work. Now after recompile I need to update the user control
with the newly compiled version (maybe something has changed). And THAT
is the problem. I can't unload assemblies from the main app domain and I
assume that I can't use another appdomain for the forms designer
(because controls can't be exchanged between domain boundaries ... and I
need to show it somewhere). Therefore all I need is a solution to the
'update' problem.

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.
 
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
 
I don't know what the VS.NET designer does. You are correct as far as #1.
That's why you have to create a really good interface/class that will NOT
change, and can safely be loaded into both app domains, and can do the
appropriate communication between domains. The way I envision this
happening is that the shell and UI are all in your 'primary domain'. You
then start a secondary domain for the toolbox and designer. All code that
deals directly with control types has to go in the secondary domain. Then
whenever a control needs to be refreshed, you restart the secondary domain.
 
Back
Top