By now you've heard a lot of talk about how .Net's Common Language Runtime (CLR) promises to let developers write code in numerous languages and then assemble them for use in the .Net framework. (I covered the basics of this approach in an earlier article.) Now let's take a closer look at how developers can use the CLR to accomplish these goals. We'll also discuss how the System.Reflection interface in .Net's CLR is used to discover information about .Net objects, regardless of whether documentation on those objects exists. Finally, we dissect what happens during the runtime execution of a CLR-compliant object.
Code samples and usageVisual Studio .Net is the reference application for development tools related to .Net, but it's not the only .Net development tool. In fact, you might not need it at all. Visual Studio .Net is a little pricey at $1,900 per seat; MSDN Universal is $2,700. Multiply either of those price tags by 10 developers, and your budget may be strained. Fortunately, Visual Studio .Net has some great support for third-party and legacy languages (FORTRAN, COBOL, Perl) and of course, for the current Microsoft languages: BASIC, C#, VB.Net, and C++. All you need is the command-line compiler for the specific Common Language Specification-compliant language. C programming
In C++, developers use the #include directive when dealing with wrapper classes for COM objects, or the #import directive when importing types from C. In .Net's Managed C++, the #using directive -- in a form such as #using
Compiling a .Net PE is similar to the process in Visual BASIC. NET, but it is geared more toward the way Visual Basic programmers work, with the names of classes instead of the file names of their libraries. The Imports keyword may be used in a class module, like so:
Imports System
Public Module modSample
Sub Main()
Console.WriteLine ("Hello World!")
End Sub
End Module
Next, it may be compiled from the command line as vbc.exe /t:exe /out:MyFile.exe MyFile.vb. That /t: option is handy because it specifies into which kind of program the project will be compiled. System.Reflection
Since all .Net PEs make extensive use of metadata, it's important to be able to access that data from an application. To do this, you'll use the .Net Framework's System.Reflection capabilities. In C#, make certain the using System.Reflection directive is at the top of your code. Later in the code, you can retrieve the information about the methods exposed by the first type in the target PE's first module by using something like this: Assembly asmblyMyFile = Assembly.LoadFrom("MyFile.exe");
Module[] modMyFile = assmblyMyFile.GetModules();
Type[] typsMyFile = modMyFile[0].GetTypes();
Type oType = typsMyFile[0];
MethodInfo[] MyMethods = oType.GetMethods();
At the very least, the methods returned include GetHashCode, Equals, ToString and GetType. These four methods are common to every .Net object. Runtime execution
In my previous article, I touched on JIT compilation and how IL isn't compiled into machine code until it is needed. But, what else really happens when a .Net program runs? When the CLR executes a .Net PE, its Virtual Execution Engine takes the PE through three main phases: Class Loader, JIT Compilers, and Managed Native Code. Class Loader
During the Class Loader phase, the OS Loader reads the metadata and code modules and identifies the "entry point" (the method that is executed when the code is first run). This incorporates a complex process of loading the class from the actual file on the hard drive or across the network, caching the Type information, performing some JIT and garbage collection housekeeping, and then passing control to the JIT Compilers JIT compilers
When a method is invoked and the class is loaded, the JIT compiler checks to make sure that the code is "type-safe," Meaning that all variable types are exactly what they're supposed to be. This is one reason why VB.Net does away with the Variant type. To be safely and efficiently managed, variable types must conform to the Common Type System types. Managed native code
After the Class is verified, the JIT Compiler kicks in to turn the IL into managed native code. This happens only the first time a method is called. After that, the class loader (which tracks what code has been loaded or not) recognizes that the code is already loaded and compiled and doesn't try to retrieve and recompile the same bit of code. The compiled code remains in memory until the process shuts down. At that point, the garbage collection functions of the code manager kick in and the memory that it was using is again made available to the system. Code manager
The code manager handles the class after it has been compiled from IL into Native Code. It performs such functions as garbage collection (returning unused resources to the operating system) and exception handling (a new, more efficient way to programmatically handle errors). Ready to roll
Now you have a working knowledge of how the CLR works to allow programs written in any language to be packaged into assemblies. The resulting assemblies may run on any system supporting CLR. The CLS and the CTS, together with the IL programmers reference and MIL instruction set specification, define how the IL in an assembly can be generated, and the process it will go through to be rendered usable by the CLR.
Have your say instantly in the
Tech Update forum. Find out what's where in the new Tech Update with our
Guided Tour. Let the editors know what you think in the
Mailroom.
Tech Update forum. Find out what's where in the new Tech Update with our
Guided Tour. Let the editors know what you think in the
Mailroom.
