Plug in architecture and AppDomains

  • Thread starter Thread starter Martin Welch
  • Start date Start date
M

Martin Welch

Hi,

I need to develop a complex MDI application that suits the concept of a plug
in architecture. The plug ins will be modules containing one or several MDI
child forms.

I know that I'll need to use AppDomains to do this. Is there any sample code
available to show how this is done?

Regards,

Martin
 
Martin Welch said:
I need to develop a complex MDI application that suits the concept of a plug
in architecture. The plug ins will be modules containing one or several MDI
child forms.

I know that I'll need to use AppDomains to do this. Is there any sample code
available to show how this is done?
Click to expand...

You don't *necessarily* need to use AppDomains for that - although you
will do if you want to be able to unload plug-ins.
 
Hi,

I need to develop a complex MDI application that suits the concept of a plug
in architecture. The plug ins will be modules containing one or several MDI
child forms.

I know that I'll need to use AppDomains to do this. Is there any sample code
available to show how this is done?
Click to expand...

See:

http://msdn.microsoft.com/asp.net/community/authors/royosher
ove/default.aspx?pull=/library/en-us/dnaspp/html/pluginframe
work.asp

Or (non-wrapped version of above):

http://tinyurl.com/2rtff
 
Thanks.

I do need to unload the plug-ins.

The nearest example I've found is the AppUpdater on GotDotNet but this uses
the "Restart your app to install updates" approach.

I've written a little test app which is almost there. It loads an add-on
assembly into an appdomain and shows the child mdi form. I can unload the
appdomain but I can't then overwrite\delete the add-on's dll -- it's locked
for some reason.

My test app has the following:

main executing assembly and interfaces assembly.

Add-on assembly and interfaces assembly.

Am I right in saying that if I load my add-on assembly into another
appdomain then another copy of the interfaces assembly is loaded into the
new appdomain?

Martin
 
Martin Welch said:
I do need to unload the plug-ins.

The nearest example I've found is the AppUpdater on GotDotNet but this uses
the "Restart your app to install updates" approach.

I've written a little test app which is almost there. It loads an add-on
assembly into an appdomain and shows the child mdi form. I can unload the
appdomain but I can't then overwrite\delete the add-on's dll -- it's locked
for some reason.
Click to expand...

I think you may need to use shadow copying, or something like that. I
can't remember, exactly. I suggest you look at the source code for
NUnit, which allows assemblies to be reloaded.
 
Assembly.Load(byte[]);

This will allow you to create a dynamic, in-memory assembly, which will leave
the disk based assembly untouched. Simply open the assembly on disk for
read-only access and blast it into a byte[] to be loaded. I've done this before
with an image filter plug-in architecture. If I can dig the sample up I'll toss
it up on the web and link it here.
 
Folks,

Thanks for the links (and Justin, for the Assembly.Load(byte[]) idea).

Unfortunately they don't help me since it doesn't cover unloading the dll or
plugging into an MDI app.

The fundamental problem seems to be that Forms.MdiClient ControlCollection
is not serializable so it doesn't matter if I pass a reference to the main
form (in default appdomain) to plug-in (another appdomain) or the other way
round. Either way I get "MdiClient+ControlCollection is not marked as
serializable".

I'm now beginning to wonder if what I'm trying to attempt is actually
possible.

Any thoughts?

Thanks again.

Martin
 
Back
Top