What Is the .NET Framework?

the .NET Framework is a new and revolutionary platform created by Microsoft for developing applications.

The most interesting thing about this statement is how vague I've been — but there are good reasons for this. For a start, note that I didn't say "developing applications on the Windows operating system." Although the Microsoft release of the .NET Framework runs on the Windows operating system, it is fast becoming possible to find alternative versions that will work on others. One example of this is Mono, an open source version of the .NET Framework (including a C# compiler) that will run on several operating systems, including various flavors of Linux and Mac OS. More such projects are in the pipeline and may be available by the time you read this. In addition, you can use the Microsoft .NET Compact Framework (essentially a subset of the full .NET Framework) on personal digital assistant (PDA) class devices and even some smartphones. One of the key motivational forces behind the .NET Framework is its intended use as a means of integrating disparate operating systems.

In addition, the definition of the .NET Framework given above includes no restriction on the type of applications that are possible. This is because there is no restriction — the .NET Framework allows the creation of Windows applications, Web applications, Web services, and pretty much anything else you can think of.

the .NET Framework has been designed so that it can be used from any language. This includes the subject of this book, C#, as well as C++, Visual Basic, JScript, and even older languages such as COBOL. For this to work, .NET-specific versions of these languages have also appeared, and more are being released all the time. Not only do all of these have access to the .NET Framework, but they can also communicate with each other. It is perfectly possible for C# developers to make use of code written by Visual Basic programmers, and vice versa.

All of this provides a hitherto unthinkable level of versatility and is part of what makes using the .NET Framework such an attractive prospect.

What's in the .NET Framework?

the .NET Framework consists primarily of a gigantic library of code that you use from your client languages (such as C#) using object-oriented programming (OOP) techniques. This library is categorized into different modules — you use portions of it depending on the results you want to achieve. For example, one module contains the building blocks for Windows applications, another for network programming, and another for Web development. Some modules are divided into more specific submodules, such as a module for building Web services within the module for Web development.

The intention here is for different operating systems to support some or all of these modules, depending on their characteristics. A PDA, for example, would include support for all the core .NET functionality, but is unlikely to require some of the more esoteric modules.

Part of the .NET Framework library defines some basic types. A type is a representation of data, and specifying some of the most fundamental of these (such as "a 32-bit signed integer") facilitates interoper- ability between languages using the .NET Framework. This is called the the Common Type System (CTS).

As well as supplying this library, the Framework also includes the .NET Common Language Runtime (CLR), which is responsible for maintaining the execution of all applications developed using the .NET library.

How Do I Write Applications Using the .NET Framework?

Writing an application using the .NET Framework means writing code (using any of the languages that support the Framework) using the .NET code library. In this book you use VS for your development — VS is a powerful, integrated development environment that supports C# (as well as managed and unmanaged C++, Visual Basic, and some others). The advantage of this environment is the ease with which .NET features can be integrated into your code. The code that you will create will be entirely C# but will use the .NET Framework throughout, and you make use of the additional tools in VS where necessary.

In order for C# code to execute, it must be converted into a language that the target operating system understands, known as native code. This conversion is called compiling code, an act that is performed by a compiler. Under the .NET Framework, however, this is a two-stage process.

MSIL and JIT

When you compile code that uses the .NET Framework library, you don't immediately create operating system–specific native code. Instead, you compile your code into Microsoft Intermediate Language (MSIL) code. This code isn't specific to any operating system and isn't specific to C#. Other .NET languages — for example, Visual Basic .NET — also compile to this language as a first stage. This compilation step is carried out by VS when you use it to develop C# applications.

Obviously, to execute an application more work is necessary. This is the job of a Just-in-Time (JIT) compiler, which compiles MSIL into native code that is specific to the OS and machine architecture being targeted. Only at this point can the OS execute the application. the just-in-time part of the name here reflects the fact that MSIL code is only compiled as and when it is needed.

In the past, it was often necessary to compile your code into several applications, each of which targeted a specific operating system and CPU architecture. Often, this was a form of optimization (to get code to run faster on an AMD chipset, for example), but at times it was critical (for applications to work in both Win9x and WinNT/2000 environments, for example). This is now unnecessary, because JIT compilers (as their name suggests) use MSIL code, which is independent of the machine, operating system, and CPU. Several JIT compilers exist, each targeting a different architecture, and the appropriate one will be used to create the native code required.

The beauty of all this is that it requires a lot less work on your part — in fact, you can just forget about system-dependent details and concentrate on the more interesting functionality of your code.

Assemblies

When you compile an application, the MSIL code created is stored in an assembly. Assemblies include both executable application files that you can run directly from Windows without the need for any other programs (these have a .exe file extension), and libraries for use by other applications (which have a .dll extension).

As well as containing MSIL, assemblies also contain meta information (that is, information about the information contained in the assembly, also known as metadata) and optional resources (additional data used by the MSIL, such as sound files and pictures). The meta information allows assemblies to be fully self-descriptive. You need no other information to use an assembly, meaning that you avoid situations such as failing to add required data to the system registry and so on, which was often a problem when developing with other platforms.

This means that deploying applications is often as simple as copying the files into a directory on a remote computer. Since no additional information is required on the target systems, you can just run an executable file from this directory and (assuming the .NET CLR is installed) away you go.

Of course, you won't necessarily want to include everything required to run an application in one place. You might write some code that performs tasks required by multiple applications. In situations like this, it is often useful to place this reusable code in a place accessible to all applications. In the .NET Framework, this is the the Global Assembly Cache (GAC). Placing code in this cache is simple — you just place the assembly containing the code in the directory containing this cache.

Managed Code

The role of the CLR doesn't end once you have compiled your code to MSIL, and a JIT compiler has compiled this to native code. Code written using the .NET Framework is managed when it is executed (this stage is usually referred to as being at runtime). This means that the CLR looks after your applications by managing memory, handling security, allowing cross-language debugging, and so on. By contrast, applications that do not run under the control of the CLR are said to be unmanaged and certain languages such as C++ can be used to write such applications that, for example, access low-level functions of the operating system. However, in C# you can write only code that runs in a managed environment. You will make use of the managed features of the CLR and allow .NET itself to handle any interaction with the operating system.

Garbage Collection

One of the most important features of managed code is the concept of garbage collection. This is the .NET method of making sure that the memory used by an application is freed up completely when the application is no longer in use. Prior to .NET this has mostly been the responsibility of programmers, and a few simple errors in code could result in large blocks of memory mysteriously disappearing as a result of being allocated to the wrong place in memory. This usually meant a progressive slowdown of your computer followed by a system crash.

.NET garbage collection works by inspecting the memory of your computer every so often and removing anything from it that is no longer needed. There is no set timeframe for this; it might happen thousands of times a second, once every few seconds, or whenever, but you can rest assured that it will happen.

There are some implications for programmers here. Since this work is done for you at an unpredictable time applications have to be designed with this in mind. Code that requires a lot of memory to run should tidy itself up rather than waiting for garbage collection to happen, but this isn't anything like as tricky as it sounds.

Fitting It Together

Before moving on, I'll summarize the steps required to create a .NET application as discussed previously:

1. Application code is written using a .NET-compatible language such as C#, as shown in Figure 1-1.

   
   Figure 1-1

2. This code is compiled into MSIL, which is stored in an assembly, as shown in Figure 1-2.

   
   Figure 1-2

3. When this code is executed (either in its own right if it is an executable or when it is used from other code) it must first be compiled into native code using a JIT compiler, as shown in Figure 1-3.

   
   Figure 1-3

4. The native code is executed in the context of the managed CLR, along with any other running applications or processes, as shown in Figure 1-4.

   
   Figure 1-4

Linking

There is one additional point to note concerning the preceding process. The C# code that compiles into MSIL in step 2 needn't be contained in a single file. It is possible to split application code across multiple source code files, which are then compiled together into a single assembly. This process is known as linking and is extremely useful. The reason for this is that it is far easier to work with several smaller files than one enormous one. You can separate out logically related code into an individual file, so that it can be worked on independently and then practically forgotten about when completed. This also makes it much easier to locate specific pieces of code when you need them and enables teams of developers to divide up the programming burden into manageable chunks, where individuals can "check out" pieces of code to work on without risking damage to otherwise satisfactory sections or sections that other people are working on.