The Common Language Runtime

 
Chapter 1 - C# and .NET Architecture
bySimon Robinsonet al.
Wrox Press 2002
  

Central to the .NET framework is its run-time execution environment, known as the Common Language Runtime ( CLR ) or the .NET runtime . Code running under the control of the CLR is often termed managed code.

However, before it can be executed by the CLR, any sourcecode that we develop (in C# or some other language) needs to be compiled. Compilation occurs in two steps in .NET:

  1. Compilation of source code to Microsoft Intermediate Language ( MS - IL )

  2. Compilation of IL to platform-specific code by the CLR

At first sight this might seem a rather long-winded compilation process. Actually, this two-stage compilation process is very important, because the existence of the Microsoft Intermediate Language (managed code) is the key to providing many of the benefits of .NET. Let's see why.

Advantages of Managed Code

Microsoft Intermediate Language (often shortened to "Intermediate Language", or "IL") shares with Java byte code the idea that it is a low-level language with a simple syntax (based on numeric codes rather than text), which can be very quickly translated into native machine code. Having this well-defined universal syntax for code has significant advantages.

Platform Independence

First, it means that the same file containing byte code instructions can be placed on any platform; at runtime the final stage of compilation can then be easily accomplished so that the code will run on that particular platform. In other words, by compiling to Intermediate Language we obtain platform independence for .NET, in much the same way as compiling to Java byte code gives Java platform independence.

You should note that the platform independence of .NET is only theoretical at present because, at the time of writing, .NET is only available for Windows. However, porting .NET to other platforms is being explored (see for example the Mono project, an effort to create an open source implementation of .NET, at http://www.go-mono.com/ ).

Performance Improvement

Although we previously made comparisons with Java, IL is actually a bit more ambitious than Java byte code. Significantly, IL is always Just-In-Time compiled, whereas Java byte code was often interpreted. One of the disadvantages of Java was that, on execution, the process of translating from Java byte code to native executable resulted in a loss of performance (apart from in more recent cases, where Java is JIT-compiled on certain platforms).

Instead of compiling the entire application in one go (which could lead to a slow start-up time), the JIT compiler simply compiles each portion of code as it is called (just-in-time). When code has been compiled once, the resultant native executable is stored until the application exits, so that it does not need to be recompiled the next time that portion of code is run. Microsoft argues that this process is more efficient than compiling the entire application code at the start, because of the likelihood that large portions of any application code will not actually be executed in any given run. Using the JIT compiler, such code will never get compiled.

This explains why we can expect that execution of managed IL code will be almost as fast as executing native machine code. What it doesn't explain is why Microsoft expects that we will get a performance improvement . The reason given for this is that, since the final stage of compilation takes place at run time, the JIT compiler will know exactly what processor type the program will run on. This means that it can optimize the final executable code to take advantage of any features or particular machine code instructions offered by that particular processor.

Traditional compilers will optimize the code, but they can only perform optimizations that will be independent of the particular processor that the code will run on. This is because traditional compilers compile to native executable before the software is shipped. This means that the compiler doesn't know what type of processor the code will run on beyond basic generalities, such as that it will be an x86-compatible processor or an Alpha processor. Visual Studio 6, for example, optimizes for a generic Pentium machine, so the code that it generates cannot take advantages of hardware features of Pentium III processors. On the other hand, the JIT compiler can do all the optimizations that Visual Studio 6 can, and in addition to that it will optimize for the particular processor the code is running on.

Language Interoperability

So we can see how the use of IL enables platform independence, and how JIT compilation should improve performance. However, IL also facilitates language interoperability . Simply put, you can compile to IL from one language, and this compiled code should then be interoperable with code that has been compiled to IL from another language.

You're probably now wondering which languages aside from C# are interoperable via .NET, so let's now briefly discuss how some of the other common languages fit into .NET.

VB.NET

Visual Basic is undergoing a complete revamp to bring it up to date with .NET. The way that Visual Basic has evolved over the last few years means that in its previous version, Visual Basic 6, it is not a suitable language for running .NET programs. For example, it is heavily integrated into COM, and works by exposing only event handlers as sourcecode to the developer most of the background code is not available as sourcecode. Not only that, it does not support implementation inheritance, and the standard data types Visual Basic uses are not compatible with .NET.

Visual Basic is being upgraded to Visual Basic .NET, but in the light of the previous comments, you won't be surprised to learn that the changes being made to VB are extensive. Although we might talk about an upgrade, for all practical purposes you may as well regard Visual Basic .NET as a new language. Existing VB 6 code will not compile as VB.NET code. Converting a VB 6 program to VB.NET requires extensive changes to the code. However, most of the changes can be done automatically for you by Visual Studio .NET (the upgrade of VS for use with .NET). If you attempt to read a VB 6 project into Visual Studio .NET, it will upgrade the project for you, which means that it will rewrite the VB 6 source code into VB.NET sourcecode. Although this means that the work involved for you is heavily cut down, you will need to check through the new VB.NET code to make sure that the project still works correctly.

One side effect of this is that it is no longer possible to compile VB.NET to native executable. VB.NET compiles only to IL, just as C# does. If you need to continue coding in VB 6, you may do so, but the executable code produced will completely ignore the .NET Framework, and you'll need to keep Visual Studio 6 installed if you rely on Visual Studio as your developer environment.

Managed C++

At the time of Visual C++ 6, C++ already had a large number of Microsoft-specific extensions on Windows. With Visual C++ .NET, extensions have been added to support the .NET framework. This means that existing C++ sourcecode will continue to compile to native executable without modification. It also means, however, that it will run independently of the .NET runtime. If you want your C++ code to run within the .NET Framework, then you can simply add the following line to the beginning of your code:

   #using <mscorlib.dll>   

You will also pass the flag /clr to the compiler, which will then assume you wish to compile to managed code, and will hence emit Intermediate Language instead of native machine code. The interesting thing about C++ is that when you compile to managed code, the compiler can emit IL that contains an embedded native executable. This means that you can mix managed types and unmanaged types in your C++ code. Thus the managed C++ code:

   class MyClass     {   

defines a plain C++ class, whereas the code:

   __gc class MyClass     {   

will give you a managed class, just as if you'd written the class in C# or VB.NET. Actually, an advantage of managed C++ over C# is that we can call unmanaged C++ classes from managed C++ code without having to resort to COM interop.

The compiler will raise an error if you attempt to use features that are not supported by .NET on managed types (for example, templates or multiple inheritance of classes). You will also find that you will need to use nonstandard C++ features (such as the __gc keyword shown in the above code) when using managed classes.

Because of the freedom that C++ allows in terms of low-level pointer manipulation and so on, the C++ compiler is not able to generate code that will pass the CLR's memory type safety tests. If it's important that your code is recognized by the CLR as memory type safe, then you'll need to write your sourcecode in some other language (such as C# or VB.NET).

J++ and J#

J++ itself will continue to be supported for backwards compatibility purposes only. Microsoft is not intending to further develop any platforms that compile to a Java virtual machine. Instead, Microsoft is separately developing two technologies for Java/J++ developers under the banner JUMP ( Java User Migration Path ) and the slogan "JUMP to .NET".

The first of these technologies is Visual J#. This is essentially an add-in to Visual Studio.NET that allows you to write and compile J++ code. The difference is that instead of compiling to a Java Virtual Machine, J# will compile to IL, so it will work as a .NET language. J# users will be able to take advantage of all the usual features of VS.NET. Microsoft expect that most J++ users will find it easiest to use J# if they wish to work with .NET.

The second option is a migration tool that will automatically convert J++ code into C# code. The similarities in syntax between J++ and C# are so great that this doesn't actually involve making many major changes to code structure.

Neither J# nor the language conversion tool are available as part of .NET or Visual Studio .NET itself, but are instead being supplied separately. For more information, go to http://msdn.microsoft.com/visualj/.

Scripting Languages

Scripting languages are still around, although, in general, their importance is likely to decline with the advent of .NET. JScript, on the other hand, has been upgraded to JScript.NET. ASP.NET (the upgrade of ASP intended for use with .NET, discussed later) pages may be written in JScript.NET, and it is now possible to run JScript.NET as a compiled rather than an interpreted language, and it is also possible to write strongly typed JScript.NET code. With ASP.NET there is no reason to use scripting languages in server-side web pages. VBA is, however, still used as a language for Microsoft Office and Visual Studio macros.

COM and COM+

Technically speaking, COM and COM+ aren't technologies targeted at .NET, because components based on them cannot be compiled into IL (although it's possible to do so to some degree using Managed C++, if the original COM component was written in C++). However, COM+ remains an important tool, since its features are not duplicated in .NET. Also, COM components will still work and .NET incorporates COM interoperability features that make it possible for managed code to call up COM components and vice versa (this is discussed in Chapter 17). In general, however, you will probably find it more convenient for most purposes to code new components as .NET components, so that you can take advantage of the .NET base classes as well as the other benefits of running as managed code.

  


Professional C#. 2nd Edition
Performance Consulting: A Practical Guide for HR and Learning Professionals
ISBN: 1576754359
EAN: 2147483647
Year: 2002
Pages: 244

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net