Figure 1 | Create an App Under .NET. Click here.
You need to know some boundaries and terms before diving into .NET. First, the idea of IL is nothing new. The VB and C++ compilers have generated IL for years, but no one discussed this publicly and no one documented it. The single biggest change from the way you shipped applications in the past is in the code the compiler generates. Other than the name, the new MSIL bears little resemblance to the IL of the VB6 compilers—so if you've worked with IL in the past, prepare yourself for a whole new experience. Look at an MSIL fragment generated from the GoodByeVB6 application (see Figure 2).
This code sets up a stack of eight bytes, then pushes the this pointer onto the stack and calls the get_Label1 method. Then the code pushes the desired label text onto the stack and calls the set_Text method (see the sidebar, "How to Read MSIL," for a more detailed explanation of the structure).
When you run the compiler, you generate a program that's not a true executable as we know it today. Instead, it's called an assembly (see the Glossary sidebar). An assembly is a grouping of files deployed as a single file. In today's architecture, you might think of a single executable as an assembly. More accurately, an assembly groups the executable file with any support DLLs, images, resources, or help files.
Figure 2 | Treading on Unsafe Ground. Click here.
An assembly almost always consists of at least two files: the executable and the manifest. The manifest is a list of all the files that exist inside the assembly. The executable content inside the assembly is referred to individually as a module. Conceptually, modules correspond to DLLs or EXEs; each module contains metadata, in addition to the metadata of its parent assembly. The assembly format is an enhanced version of the current Portable Executable (PE) format.
The standard PE header comes at the beginning of the file. Inside the file is the CLR header, followed by the data required to load the code into its process space—referred to as metadata (see Figure 3). Metadata describes to the execution engine how the module should be loaded, what additional files it needs, how to load those additional files, and how to interact with COM and the .NET runtime. Metadata also describes the methods, interfaces, and classes contained in the module or assembly. The information the metadata provides allows the JIT compiler to compile and run the module. The metadata section exposes much of your application's internals and eases the transition from disassembled IL to useful code.
Figure 3 | Of
| 对此文章发表了评论 |

