Loading plugins in separate AppDomains

[Pete Davis]

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, but I've just started playing
around with separate AppDomains and I'm finding that I'm not having problems
where I expected I would, so maybe someone can help me understand a bit
better.

I've read that objects instantiated in separate AppDomains need to derive
from MarshalByRefObject. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObject) in an assembly that implements the IPlugin interface.
I've done the following to create an instance of the object (path is the
path and filename of the assembly with the class, and typeFullName is the
FullName of the Type of the object):

AppDomain domain = AppDomain.CreateDomain("PluginTest");
Assembly asm = domain.Load(path);
IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;

The object appears to instantiate fine and I called two different
properties, one that returned a string and one that returned a Guid. Both
returned the correct objects.

So I'm confused. Why do I need to derive from MarshalByRefObject?

Or have I done something wrong that somehow created the object in my primary
AppDomain?

I'm not really sure I need the separate AppDomain stuff for what I'm doing,
but thought I'd play with it while I'm creating this new plugin manager to
see what all the fuss is about.

Pete

[Markus Kling]

Whe you store the plugin objects in your main AppDomain, then you've
defeated the purpose of beeing able to completly unload your plugins.

In order for the plugin assemblies only to be loaded in the second AppDomain
you must be sure that your primary AppDomain never obtains a direct
reference to a method/class/type/etc. from one of those assemblies.... you
must remote the call. This means you need a ("remote") object reference, a
class that is derieved from MarshalByRef-Object".

You loaded the Assemblies locally ;)

Hope that makes things clearer,

Markus

"Pete Davis" <pdavis68@[nospam]hotmail.com> schrieb im Newsbeitrag
news:bI********************@giganews.com...

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, but I've just started
playing around with separate AppDomains and I'm finding that I'm not
having problems where I expected I would, so maybe someone can help me
understand a bit better.

I've read that objects instantiated in separate AppDomains need to derive
from MarshalByRefObject. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObject) in an assembly that implements the IPlugin interface.
I've done the following to create an instance of the object (path is the
path and filename of the assembly with the class, and typeFullName is the
FullName of the Type of the object):

AppDomain domain = AppDomain.CreateDomain("PluginTest");
Assembly asm = domain.Load(path);
IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;

The object appears to instantiate fine and I called two different
properties, one that returned a string and one that returned a Guid. Both
returned the correct objects.

So I'm confused. Why do I need to derive from MarshalByRefObject?

Or have I done something wrong that somehow created the object in my
primary AppDomain?

I'm not really sure I need the separate AppDomain stuff for what I'm
doing, but thought I'd play with it while I'm creating this new plugin
manager to see what all the fuss is about.

Pete

[Pete Davis]

Markus,

Thanks. I suspected that I had to be doing something wrong and that I was
somehow loading the assembly locally, because I just couldn't believe it
would be that simple.

But I'm curious, the attempt to unload the AppDomain appears to work. I say
"appears" to work, in the sense that it doesn't fail. So am I to understand
the AppDomain unloaded, but the assembly itself simpy, under the hood, moved
into my local domain without any sort of notification or warning? That seems
awefully strange to me.

Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:Oo**************@TK2MSFTNGP14.phx.gbl...

Whe you store the plugin objects in your main AppDomain, then you've
defeated the purpose of beeing able to completly unload your plugins.

In order for the plugin assemblies only to be loaded in the second
AppDomain you must be sure that your primary AppDomain never obtains a
direct reference to a method/class/type/etc. from one of those
assemblies.... you must remote the call. This means you need a ("remote")
object reference, a class that is derieved from MarshalByRef-Object".

You loaded the Assemblies locally ;)

Hope that makes things clearer,

Markus

"Pete Davis" <pdavis68@[nospam]hotmail.com> schrieb im Newsbeitrag
news:bI********************@giganews.com...

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, but I've just started
playing around with separate AppDomains and I'm finding that I'm not
having problems where I expected I would, so maybe someone can help me
understand a bit better.

I've read that objects instantiated in separate AppDomains need to derive
from MarshalByRefObject. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObject) in an assembly that implements the IPlugin interface.
I've done the following to create an instance of the object (path is the
path and filename of the assembly with the class, and typeFullName is the
FullName of the Type of the object):

AppDomain domain = AppDomain.CreateDomain("PluginTest");
Assembly asm = domain.Load(path);
IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;

The object appears to instantiate fine and I called two different
properties, one that returned a string and one that returned a Guid. Both
returned the correct objects.

So I'm confused. Why do I need to derive from MarshalByRefObject?

Or have I done something wrong that somehow created the object in my
primary AppDomain?

I'm not really sure I need the separate AppDomain stuff for what I'm
doing, but thought I'd play with it while I'm creating this new plugin
manager to see what all the fuss is about.

Pete

[Markus Kling]

What I wrote was not (!) totally correct but ment to illustrate the
scenario. To be me more clear:

Code running in one application cannot directly access code or resources
from another application. The common language runtime enforces this
isolation by preventing direct calls between objects in different
application domains. Objects that pass between domains are either copied or
accessed by proxy. If the object is copied, the call to the object is local.
That is, both the caller and the object being referenced are in the same
application domain. If the object is accessed through a proxy, the call to
the object is remote. In this case, the caller and the object being
referenced are in different application domains.

You did the first thing. Copying requires the classes to be loaded ;)

Markus

Markus,

Thanks. I suspected that I had to be doing something wrong and that I was
somehow loading the assembly locally, because I just couldn't believe it
would be that simple.

But I'm curious, the attempt to unload the AppDomain appears to work. I
say "appears" to work, in the sense that it doesn't fail. So am I to
understand the AppDomain unloaded, but the assembly itself simpy, under
the hood, moved into my local domain without any sort of notification or
warning? That seems awefully strange to me.

Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:Oo**************@TK2MSFTNGP14.phx.gbl...

Whe you store the plugin objects in your main AppDomain, then you've
defeated the purpose of beeing able to completly unload your plugins.

In order for the plugin assemblies only to be loaded in the second
AppDomain you must be sure that your primary AppDomain never obtains a
direct reference to a method/class/type/etc. from one of those
assemblies.... you must remote the call. This means you need a ("remote")
object reference, a class that is derieved from MarshalByRef-Object".

You loaded the Assemblies locally ;)

Hope that makes things clearer,

Markus

"Pete Davis" <pdavis68@[nospam]hotmail.com> schrieb im Newsbeitrag
news:bI********************@giganews.com...

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, but I've just started
playing around with separate AppDomains and I'm finding that I'm not
having problems where I expected I would, so maybe someone can help me
understand a bit better.

I've read that objects instantiated in separate AppDomains need to
derive from MarshalByRefObject. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObject) in an assembly that implements the IPlugin
interface. I've done the following to create an instance of the object
(path is the path and filename of the assembly with the class, and
typeFullName is the FullName of the Type of the object):

AppDomain domain = AppDomain.CreateDomain("PluginTest");
Assembly asm = domain.Load(path);
IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;

The object appears to instantiate fine and I called two different
properties, one that returned a string and one that returned a Guid.
Both returned the correct objects.

So I'm confused. Why do I need to derive from MarshalByRefObject?

Or have I done something wrong that somehow created the object in my
primary AppDomain?

I'm not really sure I need the separate AppDomain stuff for what I'm
doing, but thought I'd play with it while I'm creating this new plugin
manager to see what all the fuss is about.

Pete

[Pete Davis]

Okay, now I'm confused again:

1: Did the assembly load into the primary app domain or the secondary
appdomain that I created?

2: If the object copies to my primary appdomain but the assembly is still
loaded into the secondary appdomain, what happens when I unload the
secondary app domain if I have removed all references to the objects that
were "copied" over? What happens if I don't remove the references?

If the object is copied into my app domain, but the secondary AppDomain and
assembly in it can be unloaded, that would more or less accomplish my
requirements. I suspect this isn't the case, though. Too simple.

Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...

What I wrote was not (!) totally correct but ment to illustrate the
scenario. To be me more clear:

Code running in one application cannot directly access code or resources
from another application. The common language runtime enforces this
isolation by preventing direct calls between objects in different
application domains. Objects that pass between domains are either copied
or accessed by proxy. If the object is copied, the call to the object is
local. That is, both the caller and the object being referenced are in the
same application domain. If the object is accessed through a proxy, the
call to the object is remote. In this case, the caller and the object
being referenced are in different application domains.

You did the first thing. Copying requires the classes to be loaded ;)

Markus

Markus,

Thanks. I suspected that I had to be doing something wrong and that I was
somehow loading the assembly locally, because I just couldn't believe it
would be that simple.

But I'm curious, the attempt to unload the AppDomain appears to work. I
say "appears" to work, in the sense that it doesn't fail. So am I to
understand the AppDomain unloaded, but the assembly itself simpy, under
the hood, moved into my local domain without any sort of notification or
warning? That seems awefully strange to me.

Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:Oo**************@TK2MSFTNGP14.phx.gbl...

Whe you store the plugin objects in your main AppDomain, then you've
defeated the purpose of beeing able to completly unload your plugins.

In order for the plugin assemblies only to be loaded in the second
AppDomain you must be sure that your primary AppDomain never obtains a
direct reference to a method/class/type/etc. from one of those
assemblies.... you must remote the call. This means you need a
("remote") object reference, a class that is derieved from
MarshalByRef-Object".

You loaded the Assemblies locally ;)

Hope that makes things clearer,

Markus

"Pete Davis" <pdavis68@[nospam]hotmail.com> schrieb im Newsbeitrag
news:bI********************@giganews.com...
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, but I've
just started playing around with separate AppDomains and I'm finding
that I'm not having problems where I expected I would, so maybe someone
can help me understand a bit better.

I've read that objects instantiated in separate AppDomains need to
derive from MarshalByRefObject. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObject) in an assembly that implements the IPlugin
interface. I've done the following to create an instance of the object
(path is the path and filename of the assembly with the class, and
typeFullName is the FullName of the Type of the object):

AppDomain domain = AppDomain.CreateDomain("PluginTest");
Assembly asm = domain.Load(path);
IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;

The object appears to instantiate fine and I called two different
properties, one that returned a string and one that returned a Guid.
Both returned the correct objects.

So I'm confused. Why do I need to derive from MarshalByRefObject?

Or have I done something wrong that somehow created the object in my
primary AppDomain?

I'm not really sure I need the separate AppDomain stuff for what I'm
doing, but thought I'd play with it while I'm creating this new plugin
manager to see what all the fuss is about.

Pete

[Markus Kling]

Hi Pete,

the common language runtime allows multiple applications to be run in a
single operating system process by using a construct called an application
domain to isolate those applications from one another. In many respects,
application domains are the CLR's equivalent of an operating system process

1: Did the assembly load into the primary app domain or the secondary
appdomain that I created?
Application domains are the smalest unit of code-loading and -unloading in
the CLR. The user code is isolated to the domain in which it is loaded. That
is, the code cannot be directly called from outside the containing
application domain, nor can it make direct calls to code loaded in other
domains.

If a single assembly is used by several applications in the same process,
the CLR will load multiple copies of it by default-one for each domain in
which the assembly is used. This is necessary since each application domain
that accesses the assembly must have a separate copy of the static data or
method to prevent references to objects in static variables from crossing
domain boundaries.

Unload can be useed to free the resources associated with a particular
domain and result in a graceful shutdown. That is, each thread running in
the domain is sent a ThreadAbort exception, then unwound to the domain
boundary, no new threads are allowed to enter the domain, and all
domain-specific data structures are then freed (the copy of the static
variables and the related CLR data structures).
2: If the object copies to my primary appdomain but the assembly is still
loaded into the secondary appdomain, what happens when I unload the
secondary app domain if I have removed all references to the objects that
were "copied" over? What happens if I don't remove the references?

Since it is a "non-domain" natural library in both cases the assembly stays
loaded. In the second case the objects can even not be garbadge collected
until the last thread dies.

For further reading start at http://msdn.microsoft.com/netframework/ecma/

Hope that helps you understand.

Markus
awisto business solutions GmbH

PS To be corrent: there is NO mechanism to "fully" unload (release all
associated memory) even a domain-neutral assembly other than shutting down
the process or completely unloading the CLR

[Willy Denoyette [MVP]]

"Pete Davis" <pdavis68@[nospam]hotmail.com> wrote in message
news:T6********************@giganews.com...

Okay, now I'm confused again:

1: Did the assembly load into the primary app domain or the secondary
appdomain that I created?

Domain.Load(assembly) loads the assembly in both, the target AD and the
current AD.
2: If the object copies to my primary appdomain but the assembly is still
loaded into the secondary appdomain, what happens when I unload the
secondary app domain if I have removed all references to the objects that
were "copied" over? What happens if I don't remove the references?

When unloading the secondary AD, the assembly is unloaded from this AD, but
stays loaded in the current (default) AD.
If the object is copied into my app domain, but the secondary AppDomain
and assembly in it can be unloaded, that would more or less accomplish my
requirements. I suspect this isn't the case, though. Too simple.

The instance of the Type you created with CreateInstance is created in the
current AD, not in the secondary domain.

Please read the documentation on Domain.Load very carefully, and add some
code that shows you where your assembly gets loaded and where your type gets
instanciated, basically AppDomain.Load is used to load an assembly in the
current AD, this is not what you are after isn't it?.
Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:O5**************@TK2MSFTNGP12.phx.gbl...

What I wrote was not (!) totally correct but ment to illustrate the
scenario. To be me more clear:

Code running in one application cannot directly access code or resources
from another application. The common language runtime enforces this
isolation by preventing direct calls between objects in different
application domains. Objects that pass between domains are either copied
or accessed by proxy. If the object is copied, the call to the object is
local. That is, both the caller and the object being referenced are in
the same application domain. If the object is accessed through a proxy,
the call to the object is remote. In this case, the caller and the object
being referenced are in different application domains.

You did the first thing. Copying requires the classes to be loaded ;)

Markus

Markus,

Thanks. I suspected that I had to be doing something wrong and that I
was somehow loading the assembly locally, because I just couldn't
believe it would be that simple.

But I'm curious, the attempt to unload the AppDomain appears to work. I
say "appears" to work, in the sense that it doesn't fail. So am I to
understand the AppDomain unloaded, but the assembly itself simpy, under
the hood, moved into my local domain without any sort of notification or
warning? That seems awefully strange to me.

Pete

"Markus Kling" <ma**********@nospam.nospam> wrote in message
news:Oo**************@TK2MSFTNGP14.phx.gbl...
Whe you store the plugin objects in your main AppDomain, then you've
defeated the purpose of beeing able to completly unload your plugins.

In order for the plugin assemblies only to be loaded in the second
AppDomain you must be sure that your primary AppDomain never obtains a
direct reference to a method/class/type/etc. from one of those
assemblies.... you must remote the call. This means you need a
("remote") object reference, a class that is derieved from
MarshalByRef-Object".

You loaded the Assemblies locally ;)

Hope that makes things clearer,

Markus

"Pete Davis" <pdavis68@[nospam]hotmail.com> schrieb im Newsbeitrag
news:bI********************@giganews.com...
> 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,
> but I've just started playing around with separate AppDomains and I'm
> finding that I'm not having problems where I expected I would, so
> maybe someone can help me understand a bit better.
>
> I've read that objects instantiated in separate AppDomains need to
> derive from MarshalByRefObject. Why is this?
>
> I have an IPlugin interface. I have a class (not derived from
> MarshalByRefObject) in an assembly that implements the IPlugin
> interface. I've done the following to create an instance of the object
> (path is the path and filename of the assembly with the class, and
> typeFullName is the FullName of the Type of the object):
>
> AppDomain domain = AppDomain.CreateDomain("PluginTest");
> Assembly asm = domain.Load(path);
> IPlugin plugin = asm.CreateInstance(typeFullName) as IPlugin;
>
> The object appears to instantiate fine and I called two different
> properties, one that returned a string and one that returned a Guid.
> Both returned the correct objects.
>
> So I'm confused. Why do I need to derive from MarshalByRefObject?
>
> Or have I done something wrong that somehow created the object in my
> primary AppDomain?
>
> I'm not really sure I need the separate AppDomain stuff for what I'm
> doing, but thought I'd play with it while I'm creating this new plugin
> manager to see what all the fuss is about.
>
> Pete
>
>