Summary

In designing the .NET Framework, Microsoft had many goals, including simpler development and deployment, cross-language interoperability, performance efficiency, security, interoperability with native platform, and so on.

The .NET Framework lets administrators control the way .NET applications run by means of configuration files. There are two types of configuration files—general-purpose and security related. There are two types of general-purpose configuration files—machine.config (to store system-wide settings) and application-specific.

The .NET Framework provides a mechanism to store and retrieve custom configuration settings from the configuration files.

The CTS defines a set of base datatypes and specifies rules for defining and extending datatypes. When managing types, the common language run-time enforces the rules defined by the CTS.

There are two important aspects of the CTS:

Reference type objects are created on the heap and value type objects are created on the stack. The framework provides a mechanism for conversion between value types and reference types. Conversion from value type to reference type is called boxing. Conversion from reference type to value type is called unboxing.

The CLS defines features that are intended to work across all .NET languages. Among other things, it defines a subset of CTS datatypes that can be used by any .NET language. CLS-compliant code in one .NET language can be reused in another .NET language.

The heart of the .NET Framework is the common language runtime. It enforces the rules of the CTS, loads the assemblies, manages execution of the code and provides runtime services to the applications.

The .NET Framework comes with two hosts for the common language runtime—a host CorExeMain that is bootstrapped in any EXE-based assembly and ASP.NET. The .NET Framework also provides APIs to host the common language runtime within your application.

Before executing a method, the JIT compiler of the runtime compiles the MSIL code of the method to native machine language code. In the process, the MSIL code is also validated (checked for invalid code) and verified for type safety. Code that is invalid can never be executed. Code that can be validated and verified is safe. Code that can be validated and not verified is unsafe.

The security mechanism of the runtime will not let any unsafe code be executed, unless the assembly containing the unsafe code is permitted to do so.

While the code is being executed, the runtime provides many services to the application. One such service is automatic memory management. The GC mechanism provided by the framework automatically collects objects that are no longer in use.

GC deals with managed objects. It is the responsibility of the implementer to clean up unmanaged resources, if any, in the class. This cleanup logic can be implemented in the destructor of the class. The compiler automatically converts the destructor to Finalize method.

Implementing Finalize is resource intensive. An alternative is to implement Dispose on the class.

There are three possible cases of how a class handles resources:

Dispose is typically implemented in all three cases. Finalize should be implemented for the first two cases.

Besides automatic memory management, the runtime provides many other services. In later chapters, we will look at some of the important services such as interoperability, security, remoting, and so on.