Re: Finding Methods using Reflection

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Daniel Bass (_at_)
Date: 02/11/04 

Date: Wed, 11 Feb 2004 12:23:12 -0000

Ian,

The idea behind plug-in architecture is that you have one interface, from
which all plugins must derive, and then instantiate. Your calling program
will then know what methods are available, and what to do with them.

This way all a program needs to know is the location of the plugin (easy if
you just enumerate through the .DLL files in a plugin folder say), then call
the methods on the interface, and let the plugin do it's thing.

Does that make sense?

I've got some code you can look at if you like...
http://www.dunesand.com/blog/developer/developer.htm

let me know if you need any more help with that.

Later.
Dan.

"Ian" <heggaton@hotmail.com> wrote in message
news:e7a86ec6.0402110245.28cf4ada@posting.google.com...
Hi, I am writing an application and am creating a plug-in interface
for it.

The application will need to 'find' the plug-in's and will then need
to find all accessible methods.

The corresponding methods will need to have a corresponding 'user
friendly' name.

Eg: public void goForward() {...} will need to have a user friendly
name of "Go Forward"

I was thinking of creating an enumeration of custom objects (or maybe
string arrays ) that will store both the method name (for reflection)
and the associated friendly name.

This however seems a bit clunky. Am I on the right track or is there
any better way to do this?

Relevant Pages

  • Re: Finding Methods using Reflection
    ... Your calling program ... > you just enumerate through the .DLL files in a plugin folder say), ... > the methods on the interface, and let the plugin do it's thing. ... Ian. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Alternative to static property in interface?
    ... But static isn't allowed in interface. ... is my plug-in architecture). ... You might want to create two interfaces - one for the plugin, ... The factory would allow you to create instances ...
    (microsoft.public.dotnet.languages.csharp)
  • C# Plugin system - same interface in two different assemblies...
    ... I am now aware that in C# if you reference the same interface from the same file in two different projects the types are actually incompatible. ... I found this out because I have written a generic plugin system for my current and future C# needs. ... When you compile and build both projects (we haven't even defined an interface which inherits from IPlugin yet, lol) and run the host.exe application, the host creates an instance of the plugin manager and tells it to load the dll produced by the MyPlugin project. ... This means that the runtime considers the interface IPlugin, which is of course defined in both assemblies so that each assembly can use it, to be different in each assembly. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Separation of API and implementation
    ... I have an API defined in one plugin, ... interface X { ... Think about what the primary characteristic of all plugins is: it provides services that one can plug it into various client contexts. ... IOW, it isn't a plugin if any of these things is not true. ...
    (comp.object)
  • Re: How to use interfaces properly...
    ... > MyInterfaceTest). ... > property on the reference to "false". ... > interface have to have its own copy of the dll that contains the ... > references that will work during development, but will also let the plugin ...
    (microsoft.public.dotnet.framework)