Best Practices For Plugins


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 4 of 4

Thread: Best Practices For Plugins

  1. #1
    Chris Schrumm Guest

    Best Practices For Plugins


    I'm looking to write an application that will allow other developers to write
    plugins. My initial idea is that the developers will use .NET Assembly .DLL's
    and that these assemblies have classes that implement a known interface.
    The program will load the assembly with a call to Assembly.LoadFrom and
    use the defined Interface to call the users code. I can then iterate through
    the classes of an assembly and look for classes that implement the plugin
    interface and instantiate these classes. This is all fine and good until
    I want to unload the code from these assemblies which according to the documentation
    I can't do.

    I've looked into AppDomains as an alternative, AppDomains can be unloaded,
    however, from reading the documentation I gather that two application domains
    can't share the same global objects directly. My initial thought was that
    the host application (the plugin host) would allow the plugin to display
    controls on a form it would provide, however, the form would be in the host's
    AppDomain and thus would be a shared global object.

    Does anyone out thier have any suggestions?



  2. #2
    Eric Gunnerson Guest

    Re: Best Practices For Plugins

    That's an interesting scenario.

    To get what you want, I think you need some sort of forwarding mechanism.
    You'd need to write a generic control that can be added to your class, and
    have that class call the add-in in the other app domain to get whatever info
    it needed to render. You might also be able to load the add-in remotely,
    cast it to your interface, and then pass that back to the main program,
    which could use it to call your add-in.

    This column might help:

    http://msdn.microsoft.com/library/de...us/dncscol/htm
    l/csharp05162002.asp

    --
    Visit the C# product team at http://www.csharp.net

    This posting is provided "AS IS" with no warranties, and confers no rights.

    "Chris Schrumm" <cschrumm@onss.com> wrote in message
    news:3e977646$1@tnews.web.devx.com...
    >
    > I'm looking to write an application that will allow other developers to

    write
    > plugins. My initial idea is that the developers will use .NET Assembly

    ..DLL's
    > and that these assemblies have classes that implement a known interface.
    > The program will load the assembly with a call to Assembly.LoadFrom and
    > use the defined Interface to call the users code. I can then iterate

    through
    > the classes of an assembly and look for classes that implement the plugin
    > interface and instantiate these classes. This is all fine and good until
    > I want to unload the code from these assemblies which according to the

    documentation
    > I can't do.
    >
    > I've looked into AppDomains as an alternative, AppDomains can be unloaded,
    > however, from reading the documentation I gather that two application

    domains
    > can't share the same global objects directly. My initial thought was that
    > the host application (the plugin host) would allow the plugin to display
    > controls on a form it would provide, however, the form would be in the

    host's
    > AppDomain and thus would be a shared global object.
    >
    > Does anyone out thier have any suggestions?
    >
    >




  3. #3
    Chris Schrumm Guest

    Re: Best Practices For Plugins


    Thanks for the link to the article.

    Chris Shcrumm



  4. #4
    Linda Guest

    Re: Best Practices For Plugins


    I am working on something that does what you're describing.

    It is a windows service (written by Microsoft) with an implementation called
    IProcessMessage. The components implement this, and the message service
    "calls" the components with the structure defined within in it.

    For examlple:
    public interface IProcessMessage
    {
    string PMMethod(string myString, int myInt)
    }

    in the component...
    public class ExampleClass: IProcessMessage
    {
    public string PMMethod(string myString, int myInt)
    {
    Do stuff
    }
    }

    in the message service...
    private void myMethod()
    {
    string myString;
    myString = PMMethod("Linda", 70);
    }

    The location of the dll is determined in the configuration file, which is
    in XML.

    The Microsoft version of this is at the following web address along with
    documention:

    http://msdn.microsoft.com/library/de...csharpmsmq.asp

    Also, I found an article that would be useful called "15 Seconds : Creating
    an Extensible Windows Service". The first part talks about the service,
    and Part 2 is on Plug-In development. It is located at:

    http://www.15seconds.com/Issue/021007.htm

    Good luck!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center