Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <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>
    singulars
    1. This table or related slice is empty.
    1. POUsing an abstract class as the contract in plugin framework
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USWill
    1. USWill
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUsing an abstract class as the contract in plugin framework
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COFrom what we have experienced, if `myPlugin` does not extend MBRO, then we get an exception that it isn't serializable. We know that `[Serializable]` would effectively instance the class in the Host's appdomain rather than the plugin's appdomain.
      singulars
      1. PO
      1. USIAbstract
    2. CO@dboarman you're getting that because you're pulling the plugin from the plugin domain BACK to the application domain. As I stated, when this happens you are endangering yourself. If you are trying to keep plugins in their own app domain, you must control every type communcated between app domains. Your plugin host must exist within the plugin domain. Types it sends back must only be those types you supply. To do otherwise risks loading plugin assemblies in your domain. Those "not serializable" exceptions are GOOD. They tell you you're doing something wrong--bringing their code over.
      singulars
      1. PO
      1. USWill
    3. CO@dboarman managing domains is a tricky process and takes some time and effort to get right. The easiest way to do it is to have a single type which you write that you unwrap in the plugin domain. This type is responsible for loading and managing plugins. Anything transmitted from the plugin domain must be a type you supply and they should be sealed to prevent plugins from returning their own versions. Creating a small scale prototype of your system can be very helpful for refining these techniques; I did that and learned a lot.
      singulars
      1. PO
      1. USWill
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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