Best Practices For Plugins

[Chris Schrumm]

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?

[Eric Gunnerson]

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

[Chris Schrumm]

Thanks for the link to the article.

Chris Shcrumm

[Linda]

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!