Implement one plug-in platform and one plug-in three minutes-based on the simplest osgi. Net plug-in framework

Do you believe that one plug-in platform and one plug-in can be implemented in three minutes? Here I will demonstrate the simplest plug-in framework in history. This demo uses the console as an example to implement a console-based plug-in framework and a console plug-in. Of course, in addition to three minutes of development of a console plug-in platform and plug-in, you can also develop winform and web, the framework is fully compatible with the console, winform and ASP.. NET application system. The development process and development specifications are completely consistent. OK. Let's cut the topic directly.

 

1. Console host-console plug-in framework

1)Create a command line Host application named consoleshell1 in Visual Studio 2008Program.

 

2)The consoleshell1 project structure is automatically generated as follows. It consists of a program. CS main program and a system service plug-in located in Bin/plugin. This project starts the plug-in framework by calling the bundleruntime. Start method in the main method, and then loads and runs all the plug-ins.

3)Compile and run the solution. At this time, eagleshell only loads the service modules of several systems. The following is the result of using uishell. osgi Remote Management Console to remotely monitor the plug-in Platform. Enter the list or l command on the console. You can see that the framework and six system service modules have been started.

 

The Remote Management Console uses the WebService exposed by the remotingmanagement module loaded by eagleshell to manage the running status of the remote framework. Currently, it supports Remote Installation, startup, stop, uninstallation, query module, and other functions. (Declaration: This console tool is based on the eagleservice of egeyeaddin open-source products. because of the tight schedule, most of the eagleservice in egeyeaddin can be reused directly.Source code. In addition, we also use the ndigester open-source component to parse XML files .)

 

So far, the architecture of a console plug-in framework has been completed.

 

2. Console plug-in

1)Add a consoleplugin project to the project demonstrated in 1 and name it consoleplugin1. Note that its location is to the console shell1 \ bin \ plugins directory.

2)The generated project consists of the activator. CS file of the module activator and manifest. xml file of the module list.

3)Modify the START () and stop () Methods of the activator class. The example is as follows:

 

1 Public   Class Activator: ibundleactivator
2 {
3 Public   Void Start (ibundlecontext context)
4 {
5 Console. writeline ( " Leleplugin1 is active. " );
6 }
7 Public   Void Stop (ibundlecontext context)
8 {
9 Console. writeline ( " Leleplugin1 is stopped. " );
10 }
11 }

 

4)So far, a basic plugin example has been created.

5)Compile the entire solution and run the console application created in the previous section. The result is as follows:

6)Run the remote management console and run the LIST command. The result is as follows: consoleplugin1 is mounted and active.

7)In the remote management console, enter "Stop 3" to stop the module. The result is as follows:

At this point, consoleplugin1 enters the resolved state and outputs "consoleplugin1 is stopped." On the Console where consoleshell runs.

 

This plug-in is also implemented! The following is a brief introduction to the terms involved in this process.

 

3 host Introduction

The plug-in framework is a module runtime framework on top of the common language runtime. It needs to be started and stopped by the host. That is to say, the host is the program that starts and stops the module runtime. In this way, the host inherits all the features of the dynamic plug-in of the plug-in framework. It supports various types of hosts, including the console, winform, and ASP. NET. The console host provides a console-based running environment for all plug-ins, while winform provides a desktop application environment and a network application environment.

4 Introduction

The activator is the entry/exit point for the plug-in platform to start the plug-in. When the module is started, the START () function of the activator is called. If the call is successful, the module enters the active state. When the module is customized, the STOP () function is called. Once the call is successful, the module enters the resolved state. Therefore, the plug-in can implement the preprocessing/cleaning function in the activator. For example, in START (), the module can register a service with the service bus, and other plug-ins can obtain the shared service here; you can also execute other operations such as the startup thread here.

5 manifest Introduction

Manifes. XML contains private definitions, dependency declarations, extensions, and extension points of various plug-ins or services. It is the only way for the plug-in to expose itself to the underlying framework, the platform can use manifest to implement a series of functions such as plug-ins and basic service support.