Osgi. Net plug-in Migration Technology: migrate ndatabase object database to osgi. Net plug-in

In essence, oop application systems are composed of types. In. net, classes are provided by the Assembly, and an application system is composed of a bunch of assembly, some of which are. NET framework is provided, some are provided by third parties, and the rest is custom assembly. An application system built based on the osgi. Net plug-in framework is composed of plug-ins. Each plug-in consists of a plug-in assembly and a plug-in list file description. This article is divided into the following topics:

● Use a tool without a line of code to migrate the Assembly into a plug-in and use

● Osgi. Net plug-in migration principle

 

1. Use tools to migrate plug-ins

Here we demonstrate using tools to migrate the. Net-based object database Assembly ndatabase (https://ndatabase.codeplex.com/, http://www.cnblogs.com/asxinyu/archive/2013/02/20/2918066.html) to the osgi. Net plug-in and apply it in the system.

(1) log on to the ndatabase website.

(2) run the plug-in migration tool and click "Open factory plug-in migration tool" on the desktop. The following wizard is displayed.

Click "add assembly", browse to the ndatabase3.dll assembly, add the list, click Next, and fill in the plug-in information.

Next, click "Next", enter the output path here, and release it to the plug-in repository.

So far, the plug-in migration has been completed, and the migrated plug-ins have been uploaded to the plug-in repository. Let's take a look at the output directory. The migration wizard creates a uishell.ndatabase3plugindirectory and uishell.ndatabase3plugin.zip file in the output directory. The plugin file is a package file of the plug-in. It generally contains two files, which are used for direct upload to the plug-in repository.

This is. We open manifest. XML can be found, it declares a uishell. the ndatabase3plugin plug-in, version 1.0.0.0, contains an ndatabase3.dll local assembly. Note that the share of the local assembly is true, and the multipleversions is false.

<?xml version="1.0" encoding="utf-8" standalone="no"?> <Bundle SymbolicName="UIShell.NDatabase3Plugin" Name="UIShell.NDatabase3Plugin" Version="1.0.0.0" InitializedState="Active" xmlns="urn:uiosp-bundle-manifest-2.0">   <Runtime>     <Assembly Path="NDatabase3.dll" Share="true" MultipleVersions="false" />   </Runtime> </Bundle>

Share is true, indicating that ndatabase3.dll of this plug-in can be used by other plug-ins; multipleversions is false, indicating that this Assembly does not support multiple versions, which makes loading of classes of traditional reflection work properly. Next I will introduce the osgi. Net plug-in migration principles.

 

2 osgi. Net plug-in migration principle

To understand the principles of osgi. Net plug-in migration, we must first understand the class loading knowledge of. NET applications. You can also look at the http://www.cnblogs.com/baihmpgy/archive/2013/02/27/CLR_Loader_And_OSGi.html (deep understanding of the CLR class loading mechanism) for a deeper understanding. Here, I will briefly describe the class loading in general cases.

 

2.1. Net assembly loading Overview

(1) Assembly Loading: after the first time the Assembly type is used, when the metadata of the type needs to be loaded, the assembly of the type is loaded to appdomain;

(2) When loading a method call, CLR checks the type used by this method and then loads the type, causing assembly loading;

(3) The loaded assembly is implemented by CLR loader. By default, it is loaded from the Global Assembly Cache and private bin path, and the Assembly Loading policy, such as assembly version redirection, is applied. If the global Assembly Cache does not contain the required assembly, use the file name corresponding to the Assembly name to search in the private bin path. Once the file is found, it starts to load. If the CLR loader does not find the Assembly at this time, an assemblyresolver event is thrown, allowing custom assembly loading.

 

2.2 Introduction to osgi. Net Assembly Loading

Osgi. net assembly loading combines the osgi class loading principle with the class loading mechanism of CLR loader, and extends the CLR loader class loading mechanism to make osgi. net can achieve the Assembly migration without changing any code of the Assembly. The following describes the class loading principle of osgi. net. The class loading of plug-ins is implemented through the assemblyresolver event and the Assembly search is performed according to the plug-in dependency sequence.

Osgi. Net classes are loaded Based on the runtime configuration node of the manifest. xml plug-in list file. This node declares the dependency between the local assembly used by the plug-in and the plug-in. Is an example of manifest. xml.

 

2.3 Migration Principles

As described above, to migrate an assembly to a plug-in, you only need to build a suitable manifest. xml file. We need to define the following information in manifest. xml:

(1) Plug-in name, version, and other basic information;

(2) The runtime node information of the plug-in. It must define several Assembly nodes to specify which Assembly the plug-in contains. However, the dependency relationship should be defined according to the actual situation;

(3) when defining an assembly node, you must specify the path of the Assembly to the manifest. xml file. manifest. XML is the Root Node path of the plug-in;

(4) After editing manifest. XML, You can package manifest. XML, program set, and required resources into a zip-uploaded plug-in repository.

 

With this introduction to osgi. Net plug-in migration, you can view the http://www.iopenworks.com/Documents/DocumentsList/UserGuide_PluginMigration video to learn how to migrate the original assembly into a plug-in within 5 minutes.