473,574 Members | 2,593 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Loading plugins in separate AppDomains

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 MarshalByRefObj ect. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
Assembly asm = domain.Load(pat h);
IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?

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
Nov 17 '05 #1
6 4491
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******** ************@gi ganews.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 MarshalByRefObj ect. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
Assembly asm = domain.Load(pat h);
IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?

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

Nov 17 '05 #2
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**********@n ospam.nospam> wrote in message
news:Oo******** ******@TK2MSFTN GP14.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******** ************@gi ganews.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 MarshalByRefObj ect. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
Assembly asm = domain.Load(pat h);
IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?

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


Nov 17 '05 #3
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**********@n ospam.nospam> wrote in message
news:Oo******** ******@TK2MSFTN GP14.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******** ************@gi ganews.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 MarshalByRefObj ect. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
Assembly asm = domain.Load(pat h);
IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?

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



Nov 17 '05 #4
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**********@n ospam.nospam> wrote in message
news:O5******** ******@TK2MSFTN GP12.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**********@n ospam.nospam> wrote in message
news:Oo******** ******@TK2MSFTN GP14.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******** ************@gi ganews.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 MarshalByRefObj ect. Why is this?

I have an IPlugin interface. I have a class (not derived from
MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
Assembly asm = domain.Load(pat h);
IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?

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



Nov 17 '05 #5
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
Nov 17 '05 #6

"Pete Davis" <pdavis68@[nospam]hotmail.com> wrote in message
news:T6******** ************@gi ganews.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(ass embly) 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**********@n ospam.nospam> wrote in message
news:O5******** ******@TK2MSFTN GP12.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**********@n ospam.nospam> wrote in message
news:Oo******** ******@TK2MSFTN GP14.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******** ************@gi ganews.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 MarshalByRefObj ect. Why is this?
>
> I have an IPlugin interface. I have a class (not derived from
> MarshalByRefObj ect) 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.Creat eDomain("Plugin Test");
> Assembly asm = domain.Load(pat h);
> IPlugin plugin = asm.CreateInsta nce(typeFullNam e) 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 MarshalByRefObj ect?
>
> 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
>
>



Nov 17 '05 #7

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

Similar topics

4
4190
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 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...
5
3173
by: Christoph Haas | last post by:
Dear coders... I'm working on an application that is supposed to support "plugins". The idea is to use the plugins as packages like this: Plugins/ __init__.py Plugin1.py Plugin2.py Plugin3.py
8
2670
by: nickdu | last post by:
I'm trying to isolate "applications" into their own application domain within a single process. I've quoted applications because it's a logical representation of an application. Basically it consists of a bunch of components supplied by some application group. I got this to work, somewhat. The problem is that the application performs...
3
4699
by: Mike Krueger | last post by:
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...
1
1266
by: ASayre | last post by:
I'm currently developing a client that connects to a server and exchanges data with the server back and forth. The client retains the data in specified classes depending on what was received. While adding a plugin type API I ran into the following problem: I want users to be able to dynamically un/re-load their plugins as needed, but...
0
1608
by: Oenone | last post by:
I have created a number of "plug-in" DLLs for my ASP.NET application which are dynamically loaded at run-time. This is done by locating the DLL file on disk and loading it using the Assembly.LoadFrom(Filename) function. It's important that the DLLs are shadowed by ASP.NET so that they can be easily updated. To get this to work I have placed...
2
1279
by: ZaX | last post by:
Good day folks, I'm working with a third-party transactionnal SDK, packaged into a few DLL. In a particular scenario, I need to have two sessions opened on the infrastructure I access thru the SDK, and I need programmatical control over the two sessions, so I can make changes in one session depending on the information I receive from the...
1
2778
by: dandorey1 | last post by:
I'm currently in the process of writing a realtime telephony application. I've designed it with a fairly simply plugin architecture. When I first started reading about this the general suggestion was to load each plugin in a seperate app domain. However performance is a large concern for me. Can anyone give me an idea of the performance...
0
2311
by: npthomson | last post by:
Hi all, This could get a bit complicated but I'll try to be as clear as possible. I've written an application that discovers plugins at runtime using reflection from a subdirectory of the application, eg: In the directory the application is installed to: \application.exe \plugins\plugin1.dll
0
7736
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language...
0
8249
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
1
7826
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For...
0
6464
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
0
5307
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert...
0
3748
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in...
0
3756
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
2252
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
1
1352
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.