I've been looking around for different methods of providing plug-in support for my application. Ideally, I will be creating a core functionality and based on different customers developing different plug-ins/addons such as importing, exporting data etc... What are the some methods available for making a C# application extensible via a plug-in architecture?
Lets make up an example. If we have a program that consists of a main menu ( File, Edit, View, et al. ) along with a TreeView that displays different brands of cars grouped by manufacturer ( Ford, GM, for now). Right clicking on a car displays a context menu with the only option being 'delete car'.
How could you develop the application so that plug-ins could be deployed so that you could allow one customer to see a new brand in the TreeView, let's say Honda, and also extent the car context menu so that they may now 'paint a car'?
In Eclipse/RCP development this is easily handled by extension points and plug-ins. How does C# handle it? I've been looking into developing my own plug-in architecture and reading up on MEF.
MEF would be a good place to start.
Glenn Block's article Managed Extensibility Framework: Building Composable Apps in .NET 4 with the Managed Extensibility Framework provides a good overview.
BTW, don't be fooled by the title - you can also get MEF for .NET 3.5 SP1.
Visual Studio 2010 uses MEF, so I think its a safe bet this is the preferred way to go at MS. System.Addin always seemed a bit heavy, but it might be a better choice if you need addins to always work and your codebase is constantly evolving.
If you care about isolating addins, you should read up on AppDomains. I've got a demo project which I made to help learn how to deal with isolating assemblies within an AppDomain here, which you might find interesting. Quick facts about isolation: Only your types should ever cross the boundary and these types should be sealed, run screaming from cross domain event handling, and addins should NEVER extend MarshallByRefObject.
Related
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 have to create a workflow in C# capable of moving an object (persisted as a database record) through an approval workflow where people are required to perform some sort of action or validation.
We initially looked at Windows Workflow Foundation but shied away from it because it seemed so infrastructure-heavy (and besides we don't really like Microsoft products). We looked at ObjectFlow because it's lightweight, but I'm having trouble figuring out how to persist & resume workflow states. It almost seems like it's too lightweight.
Does anyone have a particular favorite framework for doing workflow? I'm open to ideas (even to WWF, if you can explain why it's your favorite).
Now at the end of 2022 I recommend Elsa Workflows library which is free and open source.In this case state machine workflows works. I have used it in multiple projects witch success. It is flexible, has a web workflow designer and acceptable documents
As the question #gsharp linked to says, WF 4 isn't entirely easy to use. However, ObjectFlow has an easy fluent interface that is light and built with solid design principles. Given the apparent lack of decent workflow frameworks, I decided to pitch in and extend ObjectFlow with an IStatefulWorkflow that contains a .Yield() method capable of yielding workflow processing to the calling method so that it's state can be persisted.
The end result of my work will be a new release at codeplex in a couple weeks. Until then, you can follow my progress at github.
Have you looked at Drools.Net?
Drools.NET is a Business Rules Engine (BRE) based on Charles Forgy's Rete algorithm. Developers can now exploit a powerful Rule Engine through a completely managed .NET code base! Drools.NET is based on Jboss Rules, and comes with all the features of that Rules Engine.
I have recently developed a C# Workflow library that leverages the fluent syntax and provides compile time validation between workflow steps. A Workflow's steps can be consolidated in a single location providing maintainable code. The library is very light weight and performant.
https://www.nuget.org/packages/NetWorkflow
https://github.com/Tmarndt1/NetWorkflow
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.
I'm trying to implement a plug-in like application. I know there are already several solution out there but this is just going to be proof of the concept, nothing more. The idea would be to make the application main application almost featureless by default and then let the plugins know about each other, having them have implement all the needed features.
A couple of issues arise:
I want the plugins at runtime to know about each other through my application. That wouldn't mean that at code-time they couldn't reference other plugin's assemblies so they could use its interfaces, only that plugin-feature initialization should be always through my main app. For example: if I have both plugins X and Y loaded and Y wants to use X's features, it should "register" its interest though my application to use its features. I'd have to have a kind of "dictionary" in my application where I store all the loaded plugins. After registering for interest in my application, plugin Y would get a reference to X so it could use it. Is this a good approach?
When coding plugin Y that uses X, I'd need to reference X's assembly, so I can program against its interface. That has the issue of versioning. What if I code my plugin Y against an outdated version of plugin X? Should I always use a "central" place where all assemblies are, having there always the up to date versions of the assemblies?
Are there by chance any books out there that specifically deal with these kinds of designs for .NET?
Thanks
edit: I think people are drifting away from the 2 questions I made. I can take a look at both MEF and #develop, but I'd like to get specifics answers to the questions I made.
I recommend looking into MEF. This is a new way of doing plugins in .NET. It is the recommend way of doing new addins for VS2010, for example. I've not used it myself, but what I've looked into about it looks great. Adding this as an answer on prodding of others :)
Look into the System.AddIn namespace. It's a little lower-level than MEF, and so should give you the "implement it myself" experience you're looking for.
There is a good book on building what you are looking for: Dissecting a C# Application: Inside SharpDevelop. Here's a link: http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx
The SharpDevelop application is fully plugin-based and the book talks about how they built it, the pitfalls they faced, and how they overcame it. The book is freely available from the site, or you can buy it too.
Once I done it using this example. I loved it, but it was couple years ago, I think there might be better solutions now. As long as I remember the basic idea was that there is abstract class in your program, and your plug-ins inherit that class and compiled as DLLs... or something similar using Interfaces. Anyways that approach worked great for me. Later I added a filesystemwatcher so it could load those DLL plugins while it is running.
To load an Assembly
To get the types the assembly exposes
About the two specific issues you exposed:
1) I'm not sure what are you trying to achieve, but my guess is that you want to have lazy initialization of features, and maybe lazy loading of add-ins. If that's the goal, what you are proposing might work. So it could work like this:
The Y plugin provides a list of features it needs to use (it could be done for example through a specific interface implementation or through an xml manifest).
The X add-in implements an API which allows initializing a feature, with a method like Initialize(featureId).
The host application gets the feature list required by Y, loads/initializes the X plugin, and calls Initialize for each feature.
The host application also provides a GetFeature() method which Y can use to get a reference to a 'feature' object, which would be implemented in X.
However, if the plugin Y has direct access to the X API, I think it is unnecessary to have all that infrastructure for registering features. Y can just access the X features by directly using the X API, and Y would take care of lazy initializing each feature when required. For example, Y could just call SomeXFeature.DoSomething(), and the implementation of that class would initialize the feature the first time it is used.
2) If the API of an assembly changes, any assembly depending on it may break. Plugins are just assemblies which depend on other assemblies, so they will also break. Here are some things you can do to alleviate this problem.
Assign a version number to each plugin. This could be just the assembly version.
When loading a plugin, ensure that all dependencies can be properly satisfied (that is, all plugins on which it depends must be present and have the required version). Refuse to load the plugin if dependencies can't be satisfied.
Implement a plugin management tool, to be used for all plugin install/uninstall operations. The manager can check dependencies and report errors when trying to install plugins with unsatisfied dependencies, or when trying to uninstall a plugin on which other plugins depend.
Similar solutions are used by the Mono.Addins framework. In Mono.Addins, each add-in has a version number and a list of add-ins/versions on which it depends. When loading an add-in, the add-in engine ensures that all dependent add-ins with the correct versions are also loaded. It also provides an API and a command line tool for managing the installation of add-ins.
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