Plugins and AppDomain(s) - One or many?

[stu_pb]

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!

[David Levine]

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!

[stu_pb]

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!

[Jay B. Harlow [MVP - Outlook]]

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!

[David Levine]

"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.