Using mono to create a lightweight. NET Program runtime

?? In using mono to run a. NET program across platforms this article has a preliminary understanding of how mono and. NET programs operate. Today I want to talk about the topic "Using mono to build a lightweight. NET Runtime." Why would I have such an idea? Because mono and. NET can execute IL code, it's a logical idea for me to use mono as the runtime of a. NET program. Because. NET program requires the. NET Framework to provide run support, our programs do not run smoothly when the target device does not have the. NET Framework or the. NET Framework version wrong. Forcing the user to install. NET Framework will undoubtedly affect the user experience, before Windows XP has stopped service, the domestic software vendors in order to be compatible with these users, usually choose C + + language to write native applications, which caused the domestic. NET technology is not being valued for a long time.

Consider. NET version of compatibility

?? Before considering using mono as the runtime for a. NET application, let's consider the compatibility issue with the. NET version first. Assuming that we have built an application using the. NET Framework version 3.5, the application will run on a computer that has the. NET Framework v3.5 installed if the. NET Framework is not installed on the target computer v3.5, this application will not function properly. At this point, we can have two solutions: the first, forcing users to install the. NET Framework v3.5, whether the framework is integrated into the installation package or automatically downloaded from the Web when installing the software, obviously this way will affect the user experience to the user's impression of the application is greatly compromised, and the second, try to make the application and. NET version compatible. We know that the Android program has a minimum API version setting, which guarantees that the application will run on devices that are not below that API version. Here we choose this idea, in a. NET program, we can specify the version of the. NET Framework that the application runs by using the Supportedruntime node in the application configuration file. For example, the following configuration file guarantees that the application will run on a version between the. NET Framework v2.0 and v3.5.

<?xml version= "1.0"?  <configuration ;  <startup ;  < supportedruntime  version  = "v2.0.50727" />  <supportedruntime  version  =" v3.0 "/>  << Span class= "Hljs-title" >supportedruntime  version  =  "v3.5" />  </startup ;  </configuration ;   

While this will guarantee the compatibility of your application, the fate of your application is in the. NET Framework hands, if the user's computer does not have the. NET Framework installed we still have no way, then how to do? Let's build the Mono runtime.

Mono Run-time construction

?? As we said earlier, mono consists mainly of three parts, the C # compiler (Mcs.exe), the Mono Runtime (Mono.exe), and the base Class library. Because we're here to get the writing done. NET application runs in the Mono runtime, so what we need here is the Mono runtime (Mono.exe) and the base Class library. We set up the following directory structure:

Here are the respective structures and functions of these directories:
* Bin directory: Place the Mono runtime directory, mainly placed Mono.exe, Mono-2.0.dll, Libgio-2.0-0.dll, Libglib-2.0-0.dll, Libgthread-2.0-0.dll a total of 5 files.
* Lib directory: The directory where the Mono dependent library is placed, mainly placed. NET Library directory (this is the case for 4.0), the GAC Library directory. Where the GAC Library directory of accessibility, Mono.posix, System, System.Drawing, System.Windows.Forms a total of 5 subdirectories is our development windowsform need to use the dependent library.
* etc Directory: Put the program we wrote and its related files, the main program file name is Main.exe.

?? Well, now we have a very lightweight. NET program running environment (in fact the overall environment size around 40M), note that the above files can be installed in the installation of mono in its installation directory found. According to the information currently available to the blogger, running the file through the Mono runtime is primarily a command line and a scheme called mono embedding. In particular, the second scenario can embed the runtime directly into the program, our familiar Unity3d engine is to embed the entire script runtime embedded in the C + + program, but this method is more complex, the blogger has not yet figured out its internal mechanism, so we choose the first scenario here. But it has to use the command line, forcing ordinary users to use command-line tools is a painful thing, as we are often confused by git. Well, we'll use the program to simulate the command. What the? Use the program to simulate the command line? It can't be simpler to write in C #, okay? Please note that we are not able to use the functions in the. NET Framework because it is a bootloader, if the bootloader needs to rely on. NET, then how do we do this program?

?? Well, then write a C + + native app, it doesn't have any dependencies. In C + +, the main analog command line has winexec, ShellExecute and CreateProcess three methods, about the similarities and differences of the three methods we can understand, here we choose the simplest winexec. The code is as follows:

#include <Windows.h>int main(int agrc,char *args[]){    /* 执行命令 */    WinExec("bin\\mono.exe etc\\Main.exe",SW_NORMAL);    return0;}

We have compiled the program named Launcher.exe, placed in the root of the Mono runtime directory structure We defined earlier, this file will be exposed to the user as a startup file, when the user click on the program can open the main file Main.exe. OK, now let's verify our idea:

As a comparison, we give the program's operation under normal circumstances:

This way we are now basically out of the process. NET Framework to run, why is it basic? Because. The underlying class library in net is present as part of the. NET Framework, that is, it is not the content of the CLR. So the majority of the base class libraries we are using now are the versions of Mono, and if one of the libraries we use does not have a corresponding implementation in mono, then we need to find a way to solve the dependency problem ourselves. Now each time the program runs out of the command-line window, although not affect the use, but for a perfect person is a flaw, how to solve it? The answer is mono embedding.

Summary

?? This article implements a lightweight. NET program runtime environment through Mono, which, in a way, indirectly implements a. NET program from running in the. NET Framework. The main problem with this scenario seems to be the problem of library dependencies, we now have around 40M of volume, this is because we put the common libraries in the Lib directory, but in the actual operation, these libraries are not fully used, so how to generate the appropriate LIB directory according to the program, is an effective way to solve the volume of the runtime environment. If we were to solve this problem by hand, it would be very difficult, because in peacetime Microsoft will give these libraries to us, it is on our computer, so we have never been concerned about this problem. Now when we face this problem, reflection may be a good idea, but the verification of this idea will wait until later!

Using mono to create a lightweight. NET Program runtime