Home > Article > Backend Development > Detailed analysis of .NET Core composition system (picture)
The previous article introduced the status of .NET Core in the entire .NET platform and its relationship with the .NET Framework (original link). This article will introduce in detail the composition of the .NET Core framework and the main functions of each module, as well as how to achieve cross-platform.
The above figure describes the system composition of .NET Core. The top layer is the application layer, which is a framework set for developing UI-based applications, including ASP.NET Core (used to create web apps) and UWP (used to create Windows 10 apps).
The middle layer is a public library (CoreFX), which implements the .NET Standard Library and includes common system-level operations such as (files, networks, etc.).
Under CoreFx is the runtime environment. .NET Core includes two runtimes (CoreCLR, CoreRT). CoreCLR is a runtime based on just in time compiler (JIT), which uses cross-platform open source The compiler is RyuJIT, and CoreRT is a runtime that uses an ahead-of-time compiler (AOT). It can either use RyuJIT to implement AOT compilation or use other AOT compilers. Since AOT compiles IL into machine code in advance, it also has better startup speed and energy saving on mobile devices.
Finally, I would like to mention Roslyn, an open source cross-platform source code compiler. It is different from the two compilers just now. The JIT and AOT compilers are mainly used to compile IL into native machine code, while Roslyn compiles C# or VB. NET code is compiled into a program intermediate language (IL).
The Roslyn compiler is used to compile C# or VB.NET code into an assembly (assembly). Its compilation process is a pipeline-type process that contains a total of 4 steps. The specific process is shown in the figure below.
A. Parser(analysis)
Parse the source code according to the grammar.
B. Declaration
Generate metadata (metadata) for the code. Metadata is a collection of data tables that describes the data types and members defined in the current code, and also describes the referenced types and members.
C. Bind
Bind the generated IL code with the metadata describing it to generate a managed module.
D. Emit(Generate)
Combine one or more managed modules to generate an assembly.
When a certain method needs to be executed while the program is running, the compiled IL needs to be converted into the local machine code first, and this task is handed over to RyuJIT. It is a new generation of JIT compiler that implements AMD64 architecture for the first time. RyuJIT can generate code faster than JIT64 (previous generation compiler) to improve program running efficiency.
.NET Core Runtime (CoreCLR) and .NET Core Runtime (CoreRT) are both .NET Core runtimes (Runtime). They provide core functions similar to the .NET Framework CLR (memory management, assembly loading, security, Exceptions, thread management, etc.), can be used by all runtime-oriented languages.
The difference between CoreRT and CoreCLR is that CoreRT provides a set of AOT mechanisms that can compile .NET Core programs into native code and run on the host machine without relying on the .NET runtime. In addition, most functional codes of the two runtimes are shared, such as GC. The optimization of AOT brings many benefits:
# After compilation, a single file is generated, which contains all dependencies, including CoreRT. There is no need to install the Framework
It is machine code at startup, there is no need to generate machine code, and do not load the JIT compiler
Other optimizing compilers can be used, including LLILC, IL to CPP
CoreRT has two ways to generate machine code. The first one is to directly compile IL into machine code. By default, RyuJIT acts as an AOT compiler to compile IL into machine code. The other way is to compile C# code into C++ code. Then call the C++ compiler of the corresponding platform to optimize and compile it into machine code.
Use RyuJIT to compile into machine code
dotnet restore dotnet build --native --ilcpath\bin \Product\Windows_NT.x64.Debug\packaging\publish1
Compile and generate C++ code
dotnet restore dotnet build --native --cpp --ilcpath\bin\Product\Windows_NT.x64.Debug\packaging\ publish1 --cppcompilerflags /MTd
CoreRT also has shortcomings. It needs to be compiled once for different platforms; but everything has its own limitations. It allows engineers not to publish to platforms they do not want to support (for example, a game only supports desktops and not mobile phones).
Note: These two names cannot be used in the .NET Core RC2 version. According to the official statement, this command has been removed in the current version. The final situation will not be known until the official version is released on June 27.
CoreFX mainly contains several public libraries, such as System.Collections, System.IO, System.Xml, etc. CoreFX is an implementation of .NET Standard Library, and .NET Framework 4.6.3 is also based on .NET Standard Library. They are currently based on .NET Standard Library version 1.6, see the table below for details:
From the figure above, you can see that using JIT to compile and using AOT to compile source code and run the program are two different processes.
If you use the JIT compiler to deploy a program, you only need to package the program as IL assemblies. The compiler will compile the IL into the target machine code (Native code) before the method is executed for the first time, and AOT compilation will compile the source code during compilation. Directly compiled into target machine code.
AOT compiles source code into machine code, which has the following characteristics:
Replace reflection with static code. For example, if a value type does not override the equals method of ValueType.Equals, it will be judged equal by default. Reflection will be used to find filedinfo to determine whether the types are equal, and then compare the values. equal. In AOT compilation, because reflection is replaced, only the values can be compared for equality.
The dependent third-party class libraries and .NET Libraries are packaged into the final compiled program.
The packaged program runs on a streamlined version of the runtime (CoreRT), which mainly includes the garbage collector, and the runtime will also be packaged in the app file.
Although the reflection code will be replaced during compilation, there is nothing you can do when encountering dynamic reflection code. If a dynamic reflection call is encountered at runtime, an exception will be thrown because the corresponding metadata and implementation cannot be found. The solution is to configure the runtime directive file before compilation to specify the assembly to be used.
This section introduces the structure of .NET Core, including multiple new compilers and CoreFX that follows the .NET Standard Library. Generally speaking, .NET Core is much better than the previous .NET Framework in terms of performance and development efficiency. improvement. The key is to realize for the first time the basic technology stack of .NET's complete cross-platform capabilities.
.NET Core is based on cross-platform capabilities and has not ported APIs highly related to GUI to .NET Core. Therefore, Windows Forms or Windows Presentation Foundation (WPF) have not been ported to .NET Core. .NET Core supports Console Application and Class Library type projects.
However, Microsoft uses .NET Core in its Universal Windows Platform (UWP) development platform and uses .NET Native technology to improve its performance to a speed very close to native code.
ASP.NET Core uses a console application to drive its hosting environment Kestrel Server to support the running of ASP.NET Core programs.
The above is the detailed content of Detailed analysis of .NET Core composition system (picture). For more information, please follow other related articles on the PHP Chinese website!