System with plugins in C #

I need to develop a system for monitoring sensor information, but many sensors may be added in the future.

However, the idea would be to develop a system consisting of an application skeleton. Sensors (since each of them has its own characteristics of communication and data representation) will be added as plug-ins to the system.

How do I encode this in C #? Is this a case of component based development? Should I use dynamic libraries?

+9
c # plugins
Feb 05 '09 at 13:42
source share
7 answers

There are a huge number of special plugins for C #. One of them is described in Plugin Architecture using C # (in Project Code ). The general approach is that the host application publishes an assembly with interfaces. It lists through the folder and finds the assemblies that define the class that implements its interfaces and loads them and instantiates the classes.

In practice, you want to do more. Best if the host application defines two interfaces: IHost and IPlugIn. The IHost interface provides services that the plugin can subscribe to. IPlugIn is created using IHost.

To download a plugin, you must do more than just get the plugin. You must list all the plugins that can be downloaded. Build them each. Ask them if they can escape. Ask them to export the API to the host. Ask them to import the API from the host. Plugins should be able to ask about the existence of other plugins.

In this way, plugins can extend the application by offering more APIs.

Plugins must include events. Thus, plugins can control the process of loading and unloading plugins.

At the end of the world, you must warn the plugins that they will leave. Then take them out.

This will leave you with an application that can be written in a tiny structure and fully implemented in plugins if you want to.

As an added bonus, you should also make sure that you enable shortcuts for plugins in the plugins folder. This allows you to write an application and transfer it to someone else. They can create a plug-in in their development environment, create a shortcut for it in the application plug-ins folder and not worry about deployment after each compilation.

+10
Feb 05 '09 at 13:55
source share

Managed Extensibility Framework (MEF) is what you need here. You can also use a container of injection dependency , but this is a bit not what you would expect, although it is a viable solution in itself.

+9
Feb 05 '09 at 13:48
source share

Each sensor must implement a standard interface so that routines that process sensor lists can process them in a standard way. Include an identifier field in the interface, which is unique for each type of sensor, so you can handle special cases.

Take a look at the Reflection APIs to learn how to scan and look at the .NET Assemblies directory.

Each assembly should have a factory class, which should return a list of sensors that are in this assembly. I recommend that you make it a routine, not a function, and pass it a list, which it also adds. SensorDLL1 adds 4 sensors to the emptylist, SensorDLL2 adds 8 sensors to the list, which now has 12 sensors and so on. This approach is the most flexible in the long run.

You will need to make a naming convention to find the factory class or use the attribute. Note. I do not recommend just scanning the assembly for anything that implements your touch interface, as you may have code inside the factory that controls which sensors are available. This is useful for licensing.

+3
Feb 05 '09 at 13:54
source share

Depending on the sensors themselves, it sounds as though you will need to define a single interface that will be implemented by all sensors. Your main "application skeleton" will work against the ISensor interface and should not concern specific implementations of each of the Sensor classes / objects / components.

Regardless of whether each Sensor is just a class within the same project or whether a separate assembly is up to you, although if they are separate assemblies, you need a way to dynamically load these assemblies.

Some links that may help here:

Command template design pattern: - http://en.wikipedia.org/wiki/Command_pattern

Observer Pattern Design Template: - http://en.wikipedia.org/wiki/Observer_pattern

Dynamic assembly loading: - http://www.divil.co.uk/net/articles/plugins/plugins.asp

Hope this helps.

+1
Feb 05 '09 at 13:59
source share

We once created a plug-in system in our companyโ€™s school project in 2006, Socio. Here you can find the code here and here .

The main lesson was that it was very easy to dynamically load code in C #. If you just have a plugin DLL and an application that follows your interface and links to a common DLL in which that interface exists, it just works โ„ข.

In essence, this is what was said in his approach.

+1
Feb 05 '09 at 14:17
source share
0
Feb 05 '09 at 16:49
source share

This is a very old post, but still I thought that appPress.in would be useful for someone, where we developed a framework with plugin functionality. here we allow the plugin to change the user interface of the main application horizontally and vertically, add its own pages, connect to events such as Init, OnClick and OnChange.

0
Nov 06 '15 at 0:07
source share



All Articles