Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Abstract classes are better choices for this, imho. Its primarily because interfaces are harder to version. <a href="http://blogs.msdn.com/brada/archive/2004/04/10/111042.aspx" rel="nofollow noreferrer">This blog post</a> describes the issue you might find yourself having down the road if you don't use base classes. This rule doesn't only apply to plugins, btw.</p> <p>About your design...</p> <p>Plugins shouldn't extend MBRO. You should use your Host (which should extend MBRO) to marshall all calls across to your plugins, including handling plugin events. Its very easy to unintentionally load a plugin DLL into your main appdomain if you attempt to pull them across and use their proxies.</p> <p>For example, if the plugin returns an IEnumerable for one of its methods, it may return an implementation of IEnumerable that is defined in the plugin assembly. If that doesn't extend MBRO the main appdomain will have to load the plugin assembly.</p> <hr> <p>I've uploaded three projects dealing with appdomains here:</p> <p><a href="http://cid-f8be9de57b85cc35.skydrive.live.com/self.aspx/Public/NET%20AppDomain%20Tests/appdomaintests.zip" rel="nofollow noreferrer">http://cid-f8be9de57b85cc35.skydrive.live.com/self.aspx/Public/NET%20AppDomain%20Tests/appdomaintests.zip</a></p> <p>One is using callbacks across appdomains, the second is cross-appdomain event handling, and the third is a plugin example.</p> <p>In the plugin example, an application defines a plugin interface (its a demo, not best practices!) and a plugin host. The app loads a plugin assembly raw from disk and passes it over to the plugin appdomain via the plugin host proxy, where it is loaded. The plugin host then instantiates the plugin and uses it. But when the host returns a type defined in the plugin assembly back over into the application appdomain, the plugin assembly is loaded into the main application domain, rendering the whole plugin thing pointless.</p> <p>Best thing to avoid this is provide an abstract base class for plugins that is not marked serializable and does not extend MBRO, and to only bring back primitives or sealed types you define back across the boundary from the plugin domain.</p> <p><strong>NOTE:</strong> the projects are all 4.0 RC. You'll need this or above to run them. Otherwise you'll have to edit the project files by hand or rebuild them to get them running in b2 or 2008.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload