I’m writing an ASP.NET MVC 2 application where developers could extend it with plugins. I’ve started to consider how create a plugin system. (e.g. like Joomla’s)
I have some doubts about how to do this. I have searched over the net and I found that there are two potential solutions.
using interfaces or abstract classes to implement methods and a plugin-structure, load the assembly, cast the object to the interface and call the methods that the plugins should have when i need to hook the system.
using C# events to load the assembly and raise the events where I need to hook the system. The plugin in the constructor will register the function with the event provided by my application.
What is the best solution? What performance considerations are there? What other approaches could there be?
Rather than writing your own plugin system, you should probably consider the Managed Extensibility Framework (MEF) which is Microsoft's own plug-in framework.
Have a look at the Orchard project on Codeplex. The Microsoft developers have build a plugin mechanism similar to what you are describing. Its pretty complex stuff...
Related
i'm working on a webapplication written in C# using the ASP.NET MVC framework.
I want to allow my clients to write their own plugins for the web application. Each client get it's own database.
I got some ideas how to do this:
I will provide an interface which allows the user to upload his assembly dll. This will store the dll in a specific plugins-folder for the client.
I will provide some C# Interfaces and Attributes for Class and Method annotations.
The business logic of the server will check each plugin and search for classes and methods with these attributes or interface implementations to override or alter it's default behavior on certain points.
For performance, I'll implement some form of caching that gets invalidated every time a new plugin is uploaded.
Now my question:
How can i allow the user to write a plugin? I mean how to provide some kind of SDK for this? The user primary needs the C# interfaces and Annotations but the developer also want's to test the plugin before uploading it to the production server. Can i pack my webapplication in some kind of DLL which could be loaded by the developer for testing purposes but not read the source code? Or is there any other way of doing this?
Thank you for any info on this!
You should take a look at MEF (Managed Extensibility Framework) this is a framework Microsoft created to enable applications for plugins.
In short: You create a library with contracts (interfaces). You give that library to your customers and tell them to write plugins based on those interfaces.
Then you tell your application that when it needs IPlugin it needs to search the plugin folder for an implementation of IPlugin and use that.
Some research urls:
https://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx
http://mikehadlow.blogspot.nl/2010/10/experimental-aspnet-mvc-add-ins.html
https://blogs.msdn.microsoft.com/brada/2008/09/29/simple-introduction-to-extensible-applications-with-the-managed-extensions-framework/
http://blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx
I am working on a server side application which should dynamically load modules at startup based on whether or not they exist as assemblies. I've done something similar before, but this time it's production code and I want to use frameworks for modularization and instantization (using IoC containers). I initially found Microsoft's Prism (with Unity) to be a suitable framework to do this, but I am growing concerned as I am implementing initialization and bootstrapping. The server will not have it's own GUI and will presumably run as a windows service at a later time. (I'm developing it as a simple console application in the meantime.) Various clients (roughly one client application per module) will be developed to interact with the server over WCF.
Should I even be using Prism for such an application, since it seems so geared towards GUI-enabled applications? I stopped coding when using the base class Microsoft.Practices.Prism.UnityExtensions.UnityBootstrapper which requires implementation of a CreateShell() method. I kind of expected it to be named something like Run() or something similar. I don't really have a shell, or at least a GUI shell. Am I reading to much into this, and does it make sense to use Prism without worrying about it having potentially redundant GUI functionality? Am I using the right tool for the job?
I think you already know the answer. Prism is for client applications. Even if you get this working in your server environment, there will be a lot of the framework that's just in the way. You do want to use an IoC container and you're already using Unity for this (Prism by default uses Unity). My advice, ditch Prism and start wiring everyting using Unity. Dynamically loading assemblies is super easy. You don't need a bloated framework just for loading assemblies.
As stated in Steven's answer, Prism is intended for client applications. Unity is a good choice of dependency injection container, however I believe for your situation you would likely be much better off making use of either the Managed Extensibility Framework (MEF) or the Managed Addin framework (MAF).
Unity is primarily is used when the type mappings are known at compile time, before version 2.1, there was no out of the box support for dynamic type registrations.
The Managed Extensibility Framework is ideal at dynamically discovering types for dependency injection. See here for the amount of options it provides for dynamically loading types from runtime assemblies.
The Managed Addin Framework is a part of the .NET framework since .NET 3.5, one of it's largest features is the assembly isolation, assemblies can be loaded into separate app domains and even processes and then still be used. This is great for third party addins, if they are buggy and crash, they will not bring your application down with them.
I'm starting a new project which would greatly benefit from program add-ons. The program in its most basic form reads data from a serial port and parses it into database records. Examples of add-ons that could be written would be an auto-archive add-on, an add-on to filter records, etc. I'm writing both the program and the add-ons, but some customers need custom solutions, so instead of branching off and making a completely separate program, add-ons would be great. The simplest add-on would probably be a form who's constructor takes an object reference, manipulates the object in some way, then closes.
Unfortunately, I have absolutely no idea where to start coding, and almost as little idea where to search. Everything I search for turns up browser add-ons. From what I have gathered, I need to look into dynamic loading DLLs. Besides that, I'm clueless. Does anyone have any good resources or examples I that they know of?
I'm happy to provide more details, but this project is in its inception, so I don't have a ton of specific details (specifics kind of defeats the point of add-ons, too.)
You should seriously consider using the Managed Extensibility Framework (MEF) to handle your plugin architecture. It requires thinking about things a little differently, but it is well worth the mind-stretch.
This is a simple example to illustrate the basic technique.
codeproject.com - Plugin Architecture using C#
This article demonstrates to you how
to incorporate ... as a
plugin for another application or use
it as a standalone application.
in .NET 4 you now have the Managed Extensibility Framework (MEF) to do much of the plumbing.
In .NET 3.5 you had the System.AddIn but it was deemed by many to be far too complex.
codeproject.com - AddIn Enabled Applications with System.AddIn
AddIns (sometimes called Plugins) are
seperately compiled components that an
application can locate, load and make
use of at runtime (dynamically). An
application that has been designed to
use AddIns can be enhanced (by
developing more AddIns) without the
need for the orginal application to be
modified or recompiled and tested
You really need to look at Managed Extensibility Framework (MEF). This is specifically designed to help support add-ons and other extensibility.
A very basic description (basically, your plugins must implement a special interface):
http://martinfowler.com/eaaCatalog/plugin.html
Much better article, in C#:
http://www.drdobbs.com/184403942;jsessionid=TVLM2PGYFZZB1QE1GHPCKHWATMY32JVN
I think Reflection will play a major role.
I expirimented with an app that had a plugin folder. A filesystem watcher would watch the folder, and when a new DLL was placed in it, it would use reflection to determine which types of plugins it included, loaded them, and added them to the list of available classes, etc.
Try using the term 'add-in' or 'plug-in' for your research instead of 'add-on'. That should help some.
If you're using .Net 4, there's an add-in namespace in the framework that will get you partway there.
Writing plug-in support for an app is no simple task. You'll have to maintain pretty strict separation-of-concerns across your interfaces, you'll need to provide an interop library that defines ALL of the supported plug-in types, and you'll want to do some research into dependency injection & inversion of control, in addition to the previously-suggested reflection research.
It sounds like you might have a busy weekend doing research.
How can I develop applications in C# that can be further extended using DLL add-ins?
Like .NET Reflector can browse and load DLLs at runtime.
I searched for tutorials but I couldn't find anything. Maybe I wasn't searching using the right keywords.
Have a look at the Managed Extensibility Framework: http://mef.codeplex.com/
Basically in very brief and high-level terms, what you need to do is define one or more interfaces that your application will use to interact with the extension. Then individuals that want to write an extension for your application will implement your predefined interfaces and then register the implementation with your application. Registration could be as simple as dropping the extension DLL in a directory and your application will enumerate the directory load the extension dlls and start interacting with the classes that implement you expectd interfaces.
Take a look at for following methods for a starting point on dynamically loading assemblies and creating instances of classes at runtime
System.Activator.CreateInstance
System.Reflection.Assembly.LoadFrom
Of course there is much more to it, but this should give you a starting point.
Many popular applications such as Wordpress, WHMCS and the majority of PHP forums allow plugins to hook into core application events (such as registration, logging in, create post etc.) by simply specifying a function with a particular name.
I understand that these applications are not pre compiled, but is it possible to do something of the sort with C#? I've looked into event handlers, but it seems that you can only accomplish this if the plugin has the ability to instantiate the class that we want to hook into (or at least thats what searching has lead me to believe)
Ideally, these hooks would be into business layer class events/methods and can be hooked into by multiple objects, so it would function in either WinForms or ASP.NET MVC.
Given Alex's answer, this should be useful:
System.AddIn Tools and Samples
http://clraddins.codeplex.com/
If you design your application for extensibility, this is easy. The Managed Extensibility Framework is designed for exactly this sort of scenario, and makes it very easy.
It will be included as part of the core framework in .NET 4, but is downloadable now for use in 3.5.
There is an AddIn framework shipping with .NET 3.5. The framework provides very powerful mechanisms to expose interfaces by a host application and to manage, dynamically load-unload addins etc.
Why the core concept that comes up to my mind first, is Dependency Injection? I haven't ever played with a plug-in system in any app of mine. Does DI could help anyhow with that??
Specifics on our senerio would be helpful, but generally, You may want to explore the provider psttern.
There are 3 components:
- An abstraction of a piece of functionality, (Interface/baseClass)
- A Factory method that looks to config to determine what type of Class to create
- [your] Custom Class which extends/implements the abstraction. for example, a Membership provider class that hits a custom dasta source for user info.
This is very useful when switching out logic. If you want to create an app with swappble UI components, it is another story.
There is support for this in ASP.NET, starting with 2.0.
More info on the provider:
http://msdn.microsoft.com/en-us/library/ms972319.aspx