Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Brief Overview
There's a lot to .NET. If you've downloaded Rotor (also referred to as SSCLI), which is the open source code available for download, you'll quickly realize that there are approximately 1.9 million lines of source code in the core classes in .NET. (These classes are referred to as the BCL, for base class libraries.) Rotor code doesn't include component source or ADO.NET source code, for example, but does include source for classes in the System.Reflection.Emit namespace as well as source code for utilities such as ildasm.exe.
What you'll discover in this vast resource of code is that it may take a considerable amount of time to begin to grasp the comprehensiveness of .NET. One of the things we find is the classes in the Emit namespace, which support generating (or emitting) runnable code after a program has been compiled. This runnable code is Microsoft Intermediate Language (MSIL) code.
MSIL is analogous to Java bytecode. MSIL (or just IL) is a pseudo-assembly language code that's between the source code you write—such as Visual Basic .NET or C#—and Intel-based assembly language or machine code. When you compile a .NET program, the compiler writes an assembly that contains MSIL. When you run an assembly, the MSIL is JITted (Just-in-Time compiled) to machine code. One reason for IL, perhaps, is to support JITters for other platforms. Another is that a JITter can check security permissions before JITting and running an executable. (I'm not sure which reason is the most important at Microsoft, but I suspect it's security. Using an intermediate code offers one more opportunity to inspect code for security permissions and violations before allowing the code to execute.)
Generating IL at runtime (or emitting, as I refer to it) is part of the Reflection technology that allows your code to extend itself after you've compiled and deployed your applications. There's no other way to say it: This is cool. How cool (or practical) remains to be seen, but it's fun to use, and early experimentation suggests that there may be some very powerful and practical applications.
One drawback might be the perception that a malicious person may write a super worm or virus—code that dynamically evolves to exploit changing security countermeasures. Anything is possible, but this seems highly unlikely. The System.Reflection.Emit namespace allows a programmer to emit MSIL dynamically, but the JITter inspects the MSIL and compares what it wants to do against the security permissions established by the administrator. Even if potentially harmful code is emitted, it won't get past the JITter or the security policy without permissions.
Here's an unlikely but interesting scenario. A person downloads software and inspects it for a virus. The software passes the virus scan. After you run the software, it emits new MSIL that's supposed to scrounge around your filesystem and wreak havoc or send information back to a competitor. However, if that downloaded code doesn't have Reflection permissions, the emitting and scrounging is never going to happen. At least this is the idea. (People are clever and hackers seem to have a lot of free time.) This is why security will be another important topic, too. Using security correctly will be important.
Fortunately, you and I aren't interested in creating malicious software. We're interested in writing software that provides a benefit, and in having fun. Toward that end, the following sections demonstrate a brief emitting example. At the end of the article, I'll point you to other resources that cover this topic in greater detail.