IN THIS CHAPTER
This chapter provides a brief introduction to the world of C#. As you will see, the syntax of the language itself is fairly easy to learn. The thing that takes the most time is learning how to program on the .NET Framework using the C# language. You will see the basic syntax of the C# language, including how to declare variables, create code blocks, and of course, create your first “Hello World” application.
If you already have a working knowledge of the C# language from your experience with previous versions (either 1.0 or 1.1), you can skip this chapter and move on. Take care not to skip too many of the early chapters, as there have been enhancements to the language that are covered early on in the book, such as generics and anonymous methods. This chapter also skips over some details that you may not be aware of if you have very little exposure to programming. If you have never written software on the Windows platform (either Windows or Web-based), this is the wrong chapter, and perhaps the wrong book, for you.
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.
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.
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).
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