Writing, loading, and accessing Plug-ins (Plug-ins)

In the January 2005 issue of MSDN Magazine, you have an example of a program where the code is written in mixed mode. Is it possible to dynamically load. NET classes or DLLs and call those functions? Assuming I have a native C + + application, I want to allow users to write plug-ins for the C + + program in. NET. Just like using the LoadLibrary load DLLs in. NET.

Ravi Singh

I'm writing a plug-in application with Visual C + + 6.0, which is a DLL that outputs and receives a pure virtual interface pointer. After the DLL is loaded, the EXE invokes the C function that is output in the DLL, which returns a pure virtual interface pointer. The EXE then invokes the method on the interface and sometimes returns another interface pointer to the DLL for processing.

There are currently requests that plug-ins must be written in C#,visual Basic. NET and other languages. I don't have anything based on. NET programming experience, do not understand the communication problem between managed and unmanaged code, I found a lot of information about this, but the more I read the more confused. How can I let users write plug-ins based on. NET language?

Daniel godson

In the October 2003 issue of MSDN Magazine, there was an article on Plug-ins written by Jason Clark, but I don't mind reviewing the subject here, especially since the plugin itself is a significant part of the. NET Framework (see: Plug-ins:let Users Ad D functionality to Your. NET applications with Macros and Plug-ins). After all, one of the main purposes of the Microsoft. NET Framework is to provide a language-independent system for writing reusable software components. From the first "Hello,world" program to the present, this has become the supremacy of software development guidelines. Reusable from copy/paste to subroutine, to static link library, to DLLs and more professional vbx,ocx and COM. Although the last three items belong to different themes (they are all native DLLs), the. NET framework marks a real start because all code is compiled into Microsoft intermediate Language (MSIL). Interoperability becomes an integral component, because at the common language runtime level, all code is the same. This makes it particularly easy to write programs that support the language-neutral plug-in architecture.

So how do you take advantage of this in your C + + program? Daniel's virtual function pointer system is a handmade COM. It is the essence of COM objects: pure virtual function pointers. You can use COM for the plug-in model, and developers can write plug-ins in any. NET-oriented language, because this framework lets you create and use COM objects. But as we all know, COM coding is very complex, because it needs to consider a lot of details, such as registration, reference count, type library, and so on-these things are enough to make you think that COM is simply "cumbersome object Model" (Trouble objects). If you are writing new code and trying to simplify your daily work, then use. NET to implement a plug-in model directly, I am now discussing this topic.

Let me first answer Ray's question: Is there anything like LoadLibrary in. NET, and the answer is: Yes, you can load any frame assembly with a static method System::assembly::load (a DLL that contains a. NET Class). In addition,. NET supports reflection mechanisms. Each assembly provides all the information you need, such as what class, what method, and what interface the assembly has. There is no need to care about GUIDs, registration, reference counting, and so forth.

Before I show a more general plug-in system, I'll start with a simple example, Figure 1 is a C # class that provides a static function SayHello. Note Unlike C + +, functions are not exported separately in. NET, and each function must belong to a class, although the class can be static, meaning it does not need to be instantiated. In order to compile MyLib.cs into a library, you can do this:csc /target:library MyLib.cs

The compiler will produce a. NET assembly named MyLib.dll. To invoke SayHello from C + + through Managed Extensions, you have to write this:

#using <mscorlib.dll>
#using <MyLib.dll>
using namespace MyLib;
void main ()
{
　　MyClass::SayHello("test1");
}

The compiler links to MyLib.dll and calls the correct entry point. All of this is simple and straightforward, and it belongs to. NET. Now let's say you don't want to link mylib at compile time, but want to do dynamic linking, just like in C + + with LoadLibrary. After all, the plugin is nothing more than a link at runtime, after the application you have built and delivered. Figure 2 Does the same thing as the preceding code snippet, except that it is dynamically loaded mylib. The key function is assembly::load. Once you load the assembly, you can call Assembly::gettype to get the type information about the class (note that you must provide the fully qualified namespace and class name), and then call Type::getmethod to get information about the method, even call it, like this:

MethodInfo* m = ...; // get it
String* args[] = {"Test2"};
m->Invoke(NULL, args);