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]

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message
news:ej**************@TK2MSFTNGP10.phx.gbl...

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]

"Bob Provencher" <bp*********@incurrent.com> wrote in message
news:Oz**************@TK2MSFTNGP12.phx.gbl...

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message news:ej**************@TK2MSFTNGP10.phx.gbl...

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?

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]]

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...

"Bob Provencher" <bp*********@incurrent.com> wrote in message
news:Oz**************@TK2MSFTNGP12.phx.gbl...

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in

message

news:ej**************@TK2MSFTNGP10.phx.gbl...

> 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?

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.
"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message
news:%2***************@TK2MSFTNGP11.phx.gbl...

"Bob Provencher" <bp*********@incurrent.com> wrote in message
news:Oz**************@TK2MSFTNGP12.phx.gbl...

"Aaron Queenan" <aq*********************@contingent.com.au> wrote in message

news:ej**************@TK2MSFTNGP10.phx.gbl...

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?

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.