Re: Loading plugins in separate AppDomains

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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:bICdnRJGWb8ITO7eRVn-iA@xxxxxxxxxxxxxxx
> 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
>
>


.

Relevant Pages

  • Re: Loading plugins in separate AppDomains
    ... the attempt to unload the AppDomain appears to work. ... > Whe you store the plugin objects in your main AppDomain, ... > In order for the plugin assemblies only to be loaded in the second ... >> I've read that objects instantiated in separate AppDomains need to derive ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Loading plugins in separate AppDomains
    ... the attempt to unload the AppDomain appears to work. ... >> Whe you store the plugin objects in your main AppDomain, ... >> In order for the plugin assemblies only to be loaded in the second ... >>> playing around with separate AppDomains and I'm finding that I'm not ...
    (microsoft.public.dotnet.languages.csharp)
  • PlugIn dynamisch laden und Berechtigungen festlegen(Sandbox)
    ... Das PlugIn soll mit der ASP.NET Anwendung kommunizieren. ... 'Create a new AppDomain PolicyLevel. ... Dim domainPolicy As PolicyLevel = PolicyLevel.CreateAppDomainLevel ...
    (microsoft.public.de.german.entwickler.dotnet.csharp)
  • Re: Plugins and AppDomain(s) - One or many?
    ... I suppose that if some data was lost when the AppDomain is unloaded it is ... You could put each plugin into a separate appdomain but this ... > common/shared assemblies are dealt with, ... > also means that you must unload all the plugins to unload any of them. ...
    (microsoft.public.dotnet.general)
  • Re: Plugin difficulties
    ... if you set the ApplicationBase to the plugin directory ... > and then set the PrivateBinPath to the bin directory, ... Assemblies that are loaded in the secondary AppDomain, ...
    (microsoft.public.dotnet.framework.clr)