Before you learn the mechanics of the C# language itself, it is important that you learn the evolution of technologies that created the need for a language like C#. This section takes you on a quick tour of the history of C#, followed by an explanation of the Common Language Runtime, the Common Type System, and concluding with an overview of garbage-collected environments.
The Evolution of .NET
Before the .NET Framework was released to the public, the majority of component-oriented development for the Windows platform took the form of COM objects. Component Object Model (COM), a binary standard for creating reusable components, allowed developers to write code that solved smaller problems in smaller problem domains. By breaking down the problem into components, the solution often became easier and the components used to solve the problem could be reused to solve other similar problems.
COM offered many advantages and disadvantages. One of the most common problems with the COM standard was appropriately dubbed "DLL hell." DLL hell arose when COM interfaces were indexed in the registry and then newer versions of those components were released. Versioning often caused developers headaches due to the tightly coupled, binary nature of the standard. In addition, if a DLL's location changed on the file system without the information in the registry being modified, the COM interfaces contained within that DLL would become inaccessible. You could see examples of this when a new application was installed with a different version of some shared component, and it would not only break the new application, but all other applications using that component as well.
Other problems with development at the time included things like difficulty managing memory, slow development times, GUI controls that were typically insufficient for many tasks, as well as a lack of interoperability between languages such as C++ and Visual Basic.
As a solution to this and countless other problems with development at the time, Microsoft began working on what was then referred to as COM+ 2.0. The solution would provide a managed environment in which code would be executed that would provide for enhanced type safety, security, and an incredibly extensive library of useful classes and functions to make the lives of developers much easier. Eventually this solution became what is now the .NET Framework. Versions 1.0 and 1.1 have been released and now version 2.0 is available. In the next few sections, some of the key aspects of the .NET Framework will be discussed: the Common Language Runtime, the Common Type System, and the concept of garbage-collected managed code.
The Common Language Runtime
Before talking about the basics of C#, you need to know a little bit about how C# (and all other .NET languages) works and where it sits in relation to the various components that make the entire .NET Framework run.
One such component is the Common Language Runtime (almost exclusively referred to as the CLR). Unlike previous versions of C++ and similar languages, C# runs in a managed environment. Code that you write in C# runs inside the context of the Common Language Runtime. The runtime is responsible for managing things like memory and security and isolating your code from other code so that malicious or poorly written code can't interfere with the normal operation of your application.
Figure 1.1 illustrates the layers of .NET.
Figure 1.1. The layers of .NET.
At the top layer you have the various .NET languages (this figure only includes a few of the languages that run under the CLR). Beneath those languages you have the Base Class Library. The BCL (Base Class Library) is the collection of classes and utilities written in the .NET Framework that provide you with the fundamentals you need in order to create your applications, such as code to allow you to deal with encryption, data access, file I/O, web applications, Windows applications, and much more. As you will see throughout the book, much of the task of learning C# isn't learning the language syntax; it's learning about the vast library of the BCL. In short, the CLR is the managed execution engine that drives the code written in the BCL and any applications you create.
Don Box has written an excellent book on the Common Language Runtime that gives all the detail you can possibly imagine on what the CLR is and how it works. The book is called Essential .NET Volume I: The Common Language Runtime (ISBN 0201734117, Addison-Wesley Professional).
The Common Type System
A common problem in many programming languages is the inability to exchange data between programs written in different languages. For example, you have to take special precautions when invoking C methods from Pascal, and Pascal methods from C because of parameter ordering. In addition, strings in C consist of an array of characters that are terminated with the ASCII NULL (typically represented as \0). In Pascal, the first byte of a string actually contains the length of the string. These problems are just the tip of the iceberg. As you can tell, getting different languages to communicate with each other can be a nightmarish task (and, historically, it has been).
A solution to this is to allow all of the languages to share a common representation for data types. The Common Type System provides for a common set of data types. For example, if you refer to a string in VB.NET, C#, J#, Delphi (.NET), managed C++, or any other .NET language, you are guaranteed to be referring to the same entity. This is because the type string is actually defined within the .NET Framework itself, not the language. Removing the data type definition from the languages creates an environment where VB.NET and C# code can coexist side by side without any communication issues.
Taking Out the Trash: Coding in a Garbage-Collected Environment
As I mentioned earlier in this section, the CLR does quite a bit of memory management on your behalf. If you have used C# 1.0 or 1.1, you will be familiar with this concept. One of the components of the CLR is the Garbage Collector. When you declare new variables (we'll get to that in the next section) in C#, they are managed by the Garbage Collector. When a collection cycle takes place, the Garbage Collector examines your variables and if they are no longer in use, it will dispose of them (referred to as a collection). In Chapter 16, "Optimizing your .NET 2.0 Code," you will learn more about the Garbage Collector (GC) and how awareness of its presence while coding and designing can improve the speed of your applications. For now, it is good enough to know that the GC is there managing your memory and cleaning up after you and your variables.