Overview

I l @ ve RuBoard

The Common Language Runtime (CLR) serves many roles within the .NET system. It is an important part of the execution system, but it also plays an active part in the development and deployment of software that runs on the framework. It provides multilanguage support by managing the compilers that are used to convert source to intermediate language (IL) and from IL to native code, and it enforces program safety and security.

Let's take a look at these roles in a little more detail.

Simplification of Development

The CLR's development role is important in reducing the load that we carry in our day-to-day tasks . Using .NET, you don't need to worry about the nitty-gritty details of GUIDS, IUnknown , IDispatch , or type libraries. All this "plumbing" is taken care of by the CLR on your behalf .

Code is much more reliable because memory management is also the CLR's responsibility. The objects instantiated under the CLR do not need explicit reference counting; data that you allocate is automatically reclaimed by the Garbage Collector when your code ceases to use it. Metadata also allows dynamic binding of executables. This means that those out-of-date DLL linkage problems go away completely. Reliability is also enhanced through type safety. No detail of a structure size or the organization of members within an object is unknown, so there is never any need to worry about alignment or packing issues. Furthermore, you never need to worry about bounds-checking for arrays or buffers.

Tool Support

The CLR works hand-in-hand with tools like Visual Studio, compilers, debuggers , and profilers to make the developer's job much simpler. You don't even need Visual Studio.NET for a great development experience. A debugger provided with the SDK is almost as good as the one integrated into VS.NET. Other tools, such as the Intermediate Language Disassembler (ILDASM), take advantage of services provided by the CLR.

Multiple Language Support

The basis for multiple language support is the Common Type System and metadata. The basic data types used by the CLR are common to all languages. There are therefore no conversion issues with the basic integer, floating-point, and string types. All languages deal with all data types in the same way. There is also a mechanism for defining and managing new types.

All top-level languages compile to IL. Once the compilation is made and the metadata is generated for the object, it is easily accessible from other languages. This means that objects written in one language can be inherited in a second language. It is possible to write a class in VB and inherit from it in C#.

So far, about 15 languages are supported by the .NET framework, including C++, Visual Basic, C#, Perl, Python, JScript, Pascal, COBOL, and Smalltalk.

Deployment Made Easier

With the .NET framework, there is never any need to register components in the system. You can simply copy a component to a directory, and the CLR will make sure that it is compiled and run correctly. In the case of code written for ASP.NET, you just need to copy the basic C#, JScript, or VB source code, and the correct source to IL compiler will be invoked.

There are effectively two places into which components can be deployed. The first is the directory in which the application lives. This allows different versions of the application to coexist on the same machine. The other place is the Global Assembly Cache. This is a central store for assemblies that are accessible to all .NET applications.

Wherever the components are stored, the update procedure is very simple. You just copy the assembly into the correct directory, even if the object is running (you can't do that with a Windows DLL), and the system makes it work.

Software Isolation

Applications are isolated from one another by the CLR so that they cannot affect each other. Resources may be shared, but the share must be made explicitly. This means that a .NET system can have a sandbox approach to system security if needed. When more relaxed security or access to any particular system resource is desirable, permissions for access to files or other resources on the system are tunable on an application-by-application basis.

Type Safety and Verification

The CLR enforces security and reliability through type safety, verification and trust. Type safe code is built to conform to contracts laid out by the CLR. It only uses recognized types, only uses memory allocated to it by the memory manager and cannot access non-public data or methods of other applications or processes. A type safe program cannot get into a crash situation where it runs off into outer space and writes all over some other processes memory blocks. Verification of type-safety takes place when the code is loaded and run by the CLR. The CLR, during the process of JITing each method, looks at the metadata description of the method and verifies that it is typesafe . There are circumstances when this verification is impossible , for example, when the CLR needs to use unmanaged code from a managed object. This is often the case when a .NET class calls a Win32 DLL. In these cases code must be trusted by the CLR.

Security

The issue of security is very high on the radar for systems that can run active content or execute user scripts. As a client you don't want to allow errant programs to run wild on your machine, destroying valuable data. As a service provider you don't want to allow attacks or simple mistakes by users to bring down your whole system.

The CLR manages system security through user and code identity coupled with permission checks. The identity of the code, for example the publisher and the origin of the code, can be known and permission for the use of resources granted accordingly . This type of security is called Evidence Based Security and is a major feature of .NET. The .NET framework also provides support for role-based security using Windows NT accounts and groups.

I l @ ve RuBoard