Inside.Microsoft.NET.IL.Assembler

Introduction Why This Book Was Written To tell the truth, I don't think I had much choice in this matter. Let me explain. With Microsoft .NET technology taking the world by storm, with more and more information professionals getting involved, large numbers of books covering various aspects of this technology have started to arrive—and none too soon. Alas, virtually all of these books are dedicated to .NET-based programming in high-level languages and rapid application development (RAD) environments. No doubt this is extremely im portant, and I am sure all these books will have to be reprinted to satisfy the demand. But what about the plumbing? The .NET universe, like other information technology universes, resem bles a great pyramid turned upside down and standing on its tip. The tip on which the .NET pyramid stands is the common language runtime. The runtime converts the intermediate language (IL) binary code into platform-specific (native) machine code and executes it. Resting on top of the runtime are the .NET Framework class library, the compilers, and environments such as Microsoft Visual Studio .NET. And above them begin the layers of application development, from instrumental to end-user-oriented. The pyramid quickly grows higher and wider. This book is not exactly about the common language runtime—even though it's only the tip of the .NET pyramid, the runtime is too vast a topic to be described in detail in any book of reasonable (say, luggable) size. Rather, this book focuses on the next best thing: the .NET IL Assembler. IL assembly language (ILAsm) is a low-level language, specifically designed to describe every functional feature of the common language runtime. If the runtime can do it, ILAsm must be able to express it. Unlike high-level languages, and like other assembly languages, ILAsm is platform-driven rather than concept-driven. An assembly language usually is an exact linguistic mapping of the underlying platform, which in this case is the common language runtime. It is, in fact, so exact a mapping that this language is used for describing aspects of the runtime in the ECMA standardization documents regarding the .NET common language infrastructure. (ILAsm itself, as a part of the common language infrastructure, is a subject of this standardization effort as well.) As a result of the close mapping, it is impossible to describe an assembly language without going into significant detail about the underlying platform. So, to a great extent, this book is about the common language runtime after all. IL assembly language is very popular among .NET developers. No, I am not claiming that all .NET developers prefer to program in ILAsm rather than in Microsoft Managed C++, Microsoft Visual C# .NET, or Microsoft Visual Basic .NET. But all .NET developers use the IL Disassembler (ILDASM) now and then, and many use it on a regular basis. A cyan thunderbolt—the ILDASM icon (a silent praise for David Drake)—glows on the computer screens of .NET developers regardless of their language preferences and problem areas. And ILDASM text output is…? Yes, ILAsm source code. Virtually all books on .NET-based programming that are devoted to high-level programming languages, such as Visual C# .NET or Visual Basic .NET, or to techniques such as ADO.NET at some moment mention the IL Disassembler as a tool of choice to analyze the innards of a .NET IL executable. But these volumes stop short of explaining what the disassembly text means and how to interpret it. This is an understandable choice, given the topics of these books; the detailed description of metadata structuring and IL assembly language represents a separate issue. Now perhaps you see what I mean when I say I had no choice but to write this book. Someone had to, and because I had been given the responsibility of designing and developing IL Assembler and ILDASM, it was my obligation to see it through all the way.