473,320 Members | 2,020 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Plugins and AppDomain(s) - One or many?

I am designing a plugin system for a window application using .NET(C#
specifically). One of the requirements of the plugin system is to be able to
dynamically load/unload plugins.

My initial thought was to use System.Reflection.Assembly.Load to load the
plugins dynamically. This worked great, but I was left with no way to
dynamically unload the plugin.

So now I come to creating a new AppDomain for the plugins to reside in,
since the AppDomain can be unloaded. The problem I see with this is that
when I dynamically unload one plugin, the rest will have to be reloaded and
any data will be lost. Is that true? I could notify the plugin when it is
going to be unloaded and it could persist itself, or I could persist each
plugin automatically I suppose.

So I thought I could have an AppDomain for each plugin. Is this feasible?
Would this take up too many resources? Also in this case I would have to
have one instance of the assembly loader for each plugin since the assembly
should be loaded from inside the current application domain.

I guess I am just looking for some opinions as to which approach is the
best, easiest or hopefully both!

Thanks for your help!
Jul 21 '05 #1
4 4156
Using appdomains to isolate plugins is essentially using remoting. My
approach has been to use a single appdomain for all plugins wherever
possible and only use separate appdomains when needed. The side effect of
this grouping is that all plugins in the same appdomain will get unloaded at
the same time. You could put each plugin into a separate appdomain but this
creates its own set of problems - each plugin is now remoted to all other
objects in other appdomains. When using separate appdomains you will need to
deal with issues related to assembly probing and versioning, resolving
references to other assemblies, ensuring that versioning differences in
common/shared assemblies are dealt with, etc.

If you are still in the design phase then you could add
serialize/deserialize methods to the plugin API to aid in preserving the
state. However, this assumes that a plugin is not in the middle of an
operation that cannot be interrupted, or is resumable. For a complex system
I would imagine you will need to deal with all the intricacies this
synchronization involves - querying each to determine if it is in a state
suitable to be unloaded, requesting it get to that state if it is not ready
to be shutdown, etc.

I don't know how many resources each appdomain consumes - I don't think it
would be an issue unless you are dealing with large numbers of appdomains
(of course, this begs the question of how many constitutes a "large"
system).

I think it's easier to manage the issues with a single appdomain, but this
also means that you must unload all the plugins to unload any of them.

"stu_pb" <st****@discussions.microsoft.com> wrote in message
news:57**********************************@microsof t.com...
I am designing a plugin system for a window application using .NET(C#
specifically). One of the requirements of the plugin system is to be able
to
dynamically load/unload plugins.

My initial thought was to use System.Reflection.Assembly.Load to load the
plugins dynamically. This worked great, but I was left with no way to
dynamically unload the plugin.

So now I come to creating a new AppDomain for the plugins to reside in,
since the AppDomain can be unloaded. The problem I see with this is that
when I dynamically unload one plugin, the rest will have to be reloaded
and
any data will be lost. Is that true? I could notify the plugin when it
is
going to be unloaded and it could persist itself, or I could persist each
plugin automatically I suppose.

So I thought I could have an AppDomain for each plugin. Is this feasible?
Would this take up too many resources? Also in this case I would have to
have one instance of the assembly loader for each plugin since the
assembly
should be loaded from inside the current application domain.

I guess I am just looking for some opinions as to which approach is the
best, easiest or hopefully both!

Thanks for your help!

Jul 21 '05 #2
Thanks for the great reply!

I am still in the design phase of the app and I believe from what I have
read, and what you said, that I will use a single AppDomain and allow the
plugins the chance to serialize themselves before being unloaded.

I suppose that if some data was lost when the AppDomain is unloaded it is
not the end of the world, this should happen rarely, I can't imagine plugins
being unloaded frequently!

Here's another question then: do you think it would be possible/reasonable
for the application to automatically handle the serialization of the plugins
when one plugin is reloaded? This assumes that the Plugins are designed to
be serializable and that serialization works properly across AppDomains.
This way the unload/reload could happen transparently to the plugins
themselves (unless of course the plugins are doing some processing at the
time!).

Thanks again!

"David Levine" wrote:
Using appdomains to isolate plugins is essentially using remoting. My
approach has been to use a single appdomain for all plugins wherever
possible and only use separate appdomains when needed. The side effect of
this grouping is that all plugins in the same appdomain will get unloaded at
the same time. You could put each plugin into a separate appdomain but this
creates its own set of problems - each plugin is now remoted to all other
objects in other appdomains. When using separate appdomains you will need to
deal with issues related to assembly probing and versioning, resolving
references to other assemblies, ensuring that versioning differences in
common/shared assemblies are dealt with, etc.

If you are still in the design phase then you could add
serialize/deserialize methods to the plugin API to aid in preserving the
state. However, this assumes that a plugin is not in the middle of an
operation that cannot be interrupted, or is resumable. For a complex system
I would imagine you will need to deal with all the intricacies this
synchronization involves - querying each to determine if it is in a state
suitable to be unloaded, requesting it get to that state if it is not ready
to be shutdown, etc.

I don't know how many resources each appdomain consumes - I don't think it
would be an issue unless you are dealing with large numbers of appdomains
(of course, this begs the question of how many constitutes a "large"
system).

I think it's easier to manage the issues with a single appdomain, but this
also means that you must unload all the plugins to unload any of them.

"stu_pb" <st****@discussions.microsoft.com> wrote in message
news:57**********************************@microsof t.com...
I am designing a plugin system for a window application using .NET(C#
specifically). One of the requirements of the plugin system is to be able
to
dynamically load/unload plugins.

My initial thought was to use System.Reflection.Assembly.Load to load the
plugins dynamically. This worked great, but I was left with no way to
dynamically unload the plugin.

So now I come to creating a new AppDomain for the plugins to reside in,
since the AppDomain can be unloaded. The problem I see with this is that
when I dynamically unload one plugin, the rest will have to be reloaded
and
any data will be lost. Is that true? I could notify the plugin when it
is
going to be unloaded and it could persist itself, or I could persist each
plugin automatically I suppose.

So I thought I could have an AppDomain for each plugin. Is this feasible?
Would this take up too many resources? Also in this case I would have to
have one instance of the assembly loader for each plugin since the
assembly
should be loaded from inside the current application domain.

I guess I am just looking for some opinions as to which approach is the
best, easiest or hopefully both!

Thanks for your help!


Jul 21 '05 #3
stu_pb,
In addition to the other comments, the following MSDN Magazine article
discusses using AppDomains for plug-ins...

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

Hope this helps
Jay

"stu_pb" <st****@discussions.microsoft.com> wrote in message
news:57**********************************@microsof t.com...
I am designing a plugin system for a window application using .NET(C#
specifically). One of the requirements of the plugin system is to be able
to
dynamically load/unload plugins.

My initial thought was to use System.Reflection.Assembly.Load to load the
plugins dynamically. This worked great, but I was left with no way to
dynamically unload the plugin.

So now I come to creating a new AppDomain for the plugins to reside in,
since the AppDomain can be unloaded. The problem I see with this is that
when I dynamically unload one plugin, the rest will have to be reloaded
and
any data will be lost. Is that true? I could notify the plugin when it
is
going to be unloaded and it could persist itself, or I could persist each
plugin automatically I suppose.

So I thought I could have an AppDomain for each plugin. Is this feasible?
Would this take up too many resources? Also in this case I would have to
have one instance of the assembly loader for each plugin since the
assembly
should be loaded from inside the current application domain.

I guess I am just looking for some opinions as to which approach is the
best, easiest or hopefully both!

Thanks for your help!

Jul 21 '05 #4

"stu_pb" <st***@discussions.microsoft.com> wrote in message
news:AE**********************************@microsof t.com...
Thanks for the great reply!

I am still in the design phase of the app and I believe from what I have
read, and what you said, that I will use a single AppDomain and allow the
plugins the chance to serialize themselves before being unloaded.

I suppose that if some data was lost when the AppDomain is unloaded it is
not the end of the world, this should happen rarely, I can't imagine
plugins
being unloaded frequently!
How could data get lost?
Here's another question then: do you think it would be possible/reasonable
for the application to automatically handle the serialization of the
plugins
when one plugin is reloaded? This assumes that the Plugins are designed
to
be serializable and that serialization works properly across AppDomains.
This way the unload/reload could happen transparently to the plugins
themselves (unless of course the plugins are doing some processing at the
time!).

When you say the app handles the serialization for the plugin, do you mean
that it invokes the serialization method, or it actually performs the
serialization on behalf of the plugin? I'd be leary of trying to
serialize/deserialize on behalf of a plugin, because this will be setting
the state of the plugin and I don't believe an app can determine if it is
safe or correct to set the state of an unknown class unless you know it is
explicitly designed to support that. It's not that you can't do it, it just
seems like there are a lot of ways for this to fail. For one thing, the
plugin may have values in private fields that are not directly serliazable
yet are part of its state. For another, a plugin may have to perform a
complex initialization of another device - simply setting state wont do
this.

If it were me I would invoke a serialize/deserialize method and let the
plugin handle it itself.

I would not assume you can serialize across appdomains. For that to work all
the types the remote appdomain uses must be available to the other appdomain
doing the serliazation on its behalf, and there are a lot of ways for this
to go wrong. Again, it's not that you can't do it, its just that there are
side-issues that you will run into if you do this. Instead, you can
serialize an object into a byte stream and pass that around without a
problem, but only one side understands the contents of that stream. This
would allow you to centralize the data storage for all plugins without the
side effects.
Jul 21 '05 #5

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: Arnaud Debaene | last post by:
Hello group. I have an app which can load "plugins" assemblies that are described in the registry (each registry entry gives the full path to the plugin ..dll file). The plugins may be anywhere...
1
by: MatthewRoberts | last post by:
Howdy All, I am having difficulty with two-way communication across AppDomains in an attempt to dynamically script applications. Everything works as expected, except when using ByRef parameters....
4
by: Chris Lacey | last post by:
Hi, I'm currently writing a scheduling service which starts a number DotNet executables, each within a new AppDomain, every ten seconds. The guts of the code is as follows: // For each...
2
by: Lauren Hines | last post by:
Hello, I have read numerous post stating that the only way to unload an assembly (DLL in my case) is to create a separate AppDomain, load the assembly, then unload it by calling AppDomain.Unload....
6
by: Pete Davis | last post by:
I'm confused about what precisely the limitations are on loading plugins in separate app domains. In all my previous apps that supported plugins, I've loaded them into the same domain as the app,...
0
by: Jack Wright | last post by:
Dear All, I read the following post in this newsgroup...dated 2003-02-24 19:13:03 >>> I'm trying to kill an ASP.NET web application by using the following code. When KillAppDomain webmethod is...
4
by: stu_pb | last post by:
I am designing a plugin system for a window application using .NET(C# specifically). One of the requirements of the plugin system is to be able to dynamically load/unload plugins. My initial...
1
by: dscriv | last post by:
Hello, I have Netscape 8.0.4 (in Firefox mode) and Flash 8.0.24.0. I also have IE and Firefox installed. If I go to this page, which contains a Flash detection movie:...
12
by: John | last post by:
I have a AppDomain ID, how do I get the instance of the AppDomain Object? Please advice. Thanks in advance. John
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.