Plugin architecture [closed]

问题:

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

I am trying to understand plugin-architecture. Specifically the one used in the implmentation of Windows Live Writer. I am referring to the style where you can configure/enable/disable/add/remove additional functionality just by adding/removing DLL's(+ config).

I hope to see something similar for a web-based application. Can anyone please point me to the right direction?

Thanks in advance.

-SK

回答1:

Have look at this article. In a nutshell you need to do the following at a high level.

1. Define an interface that the plugins must implement
2. Create a sub-directory with specific permissions for the plug-in dlls to live in
3. Define a configuration section or file that specifies the type to dynamically load from the plugin dll.
4. Load dll's from the plugin configuration & directory into a secured sandbox using an AppDomain

I hope this helps.

回答2:

Your question was tagged with ASP.NET, but I didn't see any ASP.NET specific stuff in your question. Pluggable ASP.NET is possible, but hard using System.AddIn, aka MAF. I managed to create a secure web-site plug proof of concept in in about 4 days.

http://suburbandestiny.com/Tech/?p=585

http://suburbandestiny.com/Tech/?p=588

The cool thing was finally being able to run an Add-In dll in Minimum Trust, while the host app ran in full or medium trust.

I finally concluded that System.AddIn was created to solve the AddIn challenges faced by Microsoft Office, not the challenges of creating an AddIn for a web.app.

MEF is supposed to be the new shiny thing to do add-in type patterns, but I don't have any experience with it. MEF was meant to be a general solution and not just to solve problems on the MS Office team, so it is somewhat more promising.

回答3:

Basically you would need to use the AssemblyLoader to load an assembly at runtime from a specified directory, then create an instance and invoke it.

    Assembly assembly = Assembly.LoadFrom("myAssembly.dll");
    Type type = assembly.GetType("theType");
    object myInstance = Activator.CreateInstance(type);

It works best if all your plugins implement an interface that exposes a certain method...like Load(). Then you can do:

myInstance.Load()

Provided you cast myInstance to your interface.

回答4:

The auto-detection of a plugin, simply by adding a DLL(s), is encapsulated in the System.Addin namespace. Each time you restart the program, it will add/remove the given plugins. As you can see, what it will not do is add/remove a plugin while the program is still running. If you want that capability, then you will need to augment the System.Addin code by adding your own file-event mechanism that informs you that a DLL was added or removed. Of course if you want to remove a DLL for something that is alreay executing, that DLL must not have a file-lock on it. To achieve that, you would have each DLL be executed with ShadowCopy turned on.