Plugin architecture

[Aaron Queenan]

COM has many facilities to assist with creating an application with Plugin
support, for example, component categories to determine what components to
load, the OLE specification and interfaces to allow negotiation of menus and
screen real estate.

Does .NET have any inherent Plugin support or specifications? Is there any
recommended way to add Plugin support to a .NET application?

Thanks,
Aaron Queenan.

 

[Bob Provencher]

COM has many facilities to assist with creating an application with Plugin
support, for example, component categories to determine what components to
load, the OLE specification and interfaces to allow negotiation of menus and
screen real estate.

Does .NET have any inherent Plugin support or specifications? Is there any
recommended way to add Plugin support to a .NET application?

You can use fully qualified type names and the Activator to dynamically load
types that implement specific interfaces, is that what you are looking for?

-- Bob

 

[Aaron Queenan]

You can use fully qualified type names and the Activator to dynamically load
types that implement specific interfaces, is that what you are looking

for?

Partially.

That would provide a generic way to create the object, but it doesn't
provide mechanism for objects to register as offering a particular service,
or enumerating such objects, or providing a mechanism for extending the user
interface of the host.

Thanks,
Aaron.

 

[Daniel O'Connell [C# MVP]]

for?

Partially.

That would provide a generic way to create the object, but it doesn't
provide mechanism for objects to register as offering a particular
service,
or enumerating such objects, or providing a mechanism for extending the
user
interface of the host.

There is no such system in existance. You will have to write your own. While
it is possible to implement atleast most of the OLE standard, writing your
own will probably entail far less work than implementing all the OLE code
that would be required anyway(considering there are no wizards).

However, to load a component is relativly easy, Activator and reflection
makes locating components based on derivation and attributes *very* simple.
Ideally you would just use a folder or a config file that points to the
assembly and let the engine detect proper types.

 

[Paul Wardle]

We implemented plugins by attributing each DLL that contains plug-ins with
our PublishPlugInAttribute(string uri, Type type)

On startup, our app enumerates all DLLs in the app directory and reflects
upon these attributes. We then build hashtables of the URI->Type, and the
interfaces that each plug-in supports.

Once this info has been built, the app simply enumerates all plug-in URIs
that implement an interface, and create them using the associated URI. This
lowers the binding between application components - new items can be dropped
in independantly, and the coupling between them is defined by the interfaces
alone.

You can also have a DirectoryWatcher that detect plug-ins that are installed
when your app is running.

Good luck!

Paul Wardle.