First into the CLR-read the CLR via C # Note

Recently bought a book "CLR via C #" read the first chapter-the CLR's execution model, with a general understanding of the CLR and the. NET Framework that the. NET has been referring to. I understand that there is a general understanding of the terminology: CTS CLS and cli , CLR and. NET Framework, IL (intermediate Language), CIL (Common intermediate Lang Uage) and   managed codes (Managed code). How to execute a program after it has been compiled into an application in C #. CTS, CLS is part of the CLI specification, the. NET Framework is a CLI implementation of Microsoft, and of course Microsoft is the initiator of the CLI specification.   (Note: Following are notes made according to the contents of the book) according to the chapters in the book, the CLR executes the following model: Compile the source code into a managed module, merge the managed module into an assembly (assembly), load the common language runtime (CLR), Executes the code for the Assembly. What is the CLR? Reference the text in MSDN: "The. NET Framework provides a run-time environment called the Common language runtime, which runs the code and provides services that make the development process easier. compilers and tools expose the common language Runti Me ' s functionality and enable you to write code, benefits from this managed execution environment. Code that you develop with a language compiler this targets the runtime is called managed code ". The CLR is a conceptual generic term, and. NET provides a runtime environment called the CLR, which is embodied in the class library used in the coding phase, memory management, exception handling, and the compiler used in the compile phase; the execution stage JIT compiler converts IL toMachine CPU instructions. The CLR supports a variety of programming languages, with the CLR being able to develop the same project in different programming languages.   What is a managed module and how is it generated? What is an assembly and how is it generated? What is the connection between a managed module and an assembly? As the book shows, both the managed module and the assembly are PE (+) files, 32-bit or 64-bit Windows can load it, and can perform certain operations, but the managed module needs to be merged into the assembly before it can be used. So what exactly do they contain, and what is the difference between a managed module and an assembly? The managed PE file consists of 4 parts: PE32 (+) header, CLR header, Meta DataAnd IL。 IL is the managed code that compiles the build. Metadata is a binary block of data that consists of several tables. There are three kinds of tables, Defining Tables(Definition table), Referencing Tables(reference table), List Table(mainifest table). An assembly is one or more type definition files and resource files File Collection。 In all the files in the assembly, there is a file that holds the manifest (that is, the metadata contains the manifest table). The manifest is also a collection of metadata tables that contain primarily those file information that is part of the assembly. Here is a partial description of the book: "Assemblies are abstract concepts, using ' assemblies ' as a conceptual thing, a set of files can be treated as a separate entity. In the world of the CLR, assemblies are equivalent to ' components '. Each assembly that is generated can be an executable program or a DLL that ultimately manages the execution of code in these assemblies by the CLR. This means that the target machine must have the. NET Framework installed. “。 The managed module is not explicitly defined in the book and should refer to the PE file in the compiler-generated metadata table that does not contain the manifest metadata table. Common definition Metadata tables: moduledef TypeDef MethodDef FieldDef paramdef propertydef eventdef Common Reference metadata tables: AssemblyRef moduleref TypeRef MemberRef List metadata table: AssemblyDef filedef manifestresourcedef exportedtypesdef The above information can be obtained by Ildasm.exeTool to view. About the daily description here, suppose A.dll b.netmodule c.netmodule These 3 files constitute an assembly, where the A.dll file contains the Manifest data table (not included in B C), we are used to call A.dll is the assembly file, runtime A.dl L B.netmodule C.netmodule Together, the process will report an exception when a B or C runtime is missing a type and the file cannot be found. The A.dll file contains a list of data tables, with information about B and C in the list, logically thinking that A.dll already includes B.netmodule and C.netmodule. Other assemblies need to deal with B or C, but also indirectly through A, so the abbreviated name A.dll is the assembly file. So when you meet a file that is an assembly file, you need to confirm that the assembly contains additional files. In this example, B.netmodule and C.netmodule are called managed modules. Specify any of the following command-line switches, and the C # compiler will generate Assembly:/t[arget]:exe,/t[arget]:winexe,/t[arget]:appcontainerexe,/t[arget]:library, or/t[arget]:winmdobj. All of these switches cause the compiler to generate a PE file containing the manifest metadata table. The C # compiler also supports the/t[arget]:module switch. This switch instructs the compiler to generate a PE file that does not contain a manifest metadata table (sometimes called Managed Modules）。 The CLR wants to access the type, and the file must be added to the assembly. You can add modules to assemblies with the/addmodule switch when the C # compiler compiles. Assemblies can also be generated by AL.exe (Assembly Linker). AL.exe can be used as a managed module for multiple compiler builds.  ☆  generate a single-file assembly. File A.csclass program { static void Main ()  {  System.Console.WriteLine ("Hello, world!"); The A.exe generated by  }}csc/out:a.exe/target:exe/reference:mscorlib.dll A.cs (or CSC A.cs) is an assembly that can be run directly. This assembly, which is itself, does not contain other files.  ☆ generates a multi-file assembly. File A.cspublic class A { public static void Afunc ()  {  System.Console.WriteLine ("This is afunc!");  }} file B.cspublic class B { public static void Bfunc ()  {  System.Console.WriteLine ("This is bfunc!");  }}csc/out:b.netmodule/t:module B.cscsc/out:a.dll/t:library/addmodule:b.netmodule A.cs into a managed module B.netmodule, It then generates a file containing the manifest metadata table A.dll and adds b.netmodule to it. This makes up a multi-file assembly. File Tmp.csclass program { static void Main ()  {  a.afunc ();  b.bfunc ();  }}csc/r:a.dll Tmp.cs Generation Tmp.exe test Results.  ☆  generate multi-file assemblies from AL.exe. Csc/t:module A.cscsc/t:module B.csal/out:multIfilelib.dll/t:library a.netmodule b.netmodule csc/r:multifilelib.dll tmp.cs  generates Tmp.exe test results. The generated Tmp.exe is the assembly file, which contains the manifest metadata table, but does not contain IL code. How is the code in the   assembly executed? The code that can be executed in an assembly is IL. Different compilers that target the CLR can generate IL. As in the case of the book. C # source code files, C # compiler, managed modules (IL and metadata) basic source code file, basic compiler->  managed module (IL and metadata) Il source code file, IL Assembler   Managed modules (IL and meta data) (ILAsm.exe il assembler and ILDasm.exe il disassembler) high-level languages provide only a subset of the full functionality of the CLR. IL Assembly then allows developers to access the full functionality of the CLR. In short, use the most appropriate programming language to accomplish the task. First, IL code cannot be executed directly, in order to execute the method, the IL must be converted to the cost machine (native) CPU instruction. This is the responsibility of the CLR's JIT (just-in-time) compiler. In the following code example, how does the code in the assembly be executed? static void Main () {    System.Console.WriteLine ("Hello");    System.Console.WriteLine ("Goodbye") ;} When compiling a generated single-file assembly, loading the assembly into memory, in order to execute method System.Console.WriteLine, first finds the method WriteLine in the metadata of the assembly that implements the type System.Console, obtains its IL, JIT The compiler translates IL into the CPU instruction and then executes the instruction. When the  system.console.writeline function is called again, the native CPU instructions in memory are executed directly because the function has been JIT-compiled. The above is a brief procedure for assembly execution. ★  description. The description for IL. IL (intermediate Language, intermediate language) is a CPU-independent abstract machine language that needs to be transferredThe CPU instructions for the replacement machine can be executed. For Clr,il specifically refers to CIL (Common intermediate Language) originating from MSIL (Microsoft intermediate Language), after the CLI (Common Language infrastr Ucture) is now formally referred to as CIL. Specific information can be queried for CIL. For a managed description. It seems that the. NET Framework is accustomed to some things about the CLR called managed XXX. such as managed code, managed PE files, managed modules, etc. And no relationship to the CLR is directly related to the native CPU, which is called unmanaged XXX. such as unmanaged code written in the C + + compiler. . Specifically, the context can be found to describe the object.   CLI specification. Here's what's in the book: "CRLs all unfold around types." So far, this should be clear. Types expose functionality to applications and other types. By type, code written in one programming language communicates with code written in another programming language. Because the type is fundamental to the CLR, Microsof has developed a formal specification to describe the definition and behavior of the type. This is Common Type System(Common Type system,cts) ". Here's what the book says: "Objects created in different languages can communicate with each other through COM." The CLR integrates all languages, and objects created in one language have the same status in another language as objects created with the latter. This integration is possible because the CLR uses standard type sets, metadata, and the public execution environment. To create types that are easily accessible from other programming languages, you can only pick features that are supported in all other languages from your own language. To help with this, Microsoft has defined Common Language Specification(Common Language specification,cls), which defines a minimum feature set. Only this feature set is supported by any compiler, and the generated type is compatible with components generated by other CLS-compliant, CLR-oriented languages. “。 Here's what's in the book: "Clr/cts provides a feature set. Some languages expose a larger subset of the clr/cts. If the developer writes the program in IL assembly language, you can use the full functionality provided by Clr/cts. “。 Specific as shown in the book. In fact, Microsoft has standardized CTS, CLS, and so on, collectively known as the Common Language architecture (Common Language Infrastructure, CLI), specific reference Wikipedia. Here's a quote from Wikipedia: "the. NET Framework and the free and open source Mono and Portable.net is implementations of the CLI." The. NET Framework is an implementation on Windows. Mono, however, supports cross-platform and open source. At present, some of the hand tour server is using Mono. So that's why I study C # seriously. After all, it is still necessary to understand the static language of a GC. In fact, my idea is to be proficient in C C # Lua, which is the basis for scaling. I don't know if I can finish this goal in the end. Come on. This is the "CLR via C #" Errata page. Https://www.microsoftpressstore.com/store/clr-via-c-sharp-9780735667457#updates. Cited: 1) Wikipedia, Common Language infrastructure,https://en.wikipedia.org/wiki/common_language_infrastructure. 2) Wikipedia, Common intermediate language,https://en.wikipedia.org/wiki/common_intermediate_language.

First into the CLR-read the CLR via C # Note