C H A P T E R 1
C# and the .NET Framework
Before .NET
The C# programming language was designed for developing programs for Microsoft’s .NET Framework. This chapter gives a brief look at where .NET came from and its basic architecture. To start off, let’s get the name right: C# is pronounced “see sharp.”1
Windows Programming in the Late 1990s
In the late 1990s, Windows programming using the Microsoft platform had fractured into a number of branches. Most programmers were using Visual Basic, C, or C++. Some C and C++ programmers were using the raw Win32 API, but most were using Microsoft Foundation Classes (MFC). Others had moved to the Component Object Model (COM).
All these technologies had their own problems. The raw Win32 API was not object-oriented, and using it required a lot more work than MFC. MFC was object-oriented but was inconsistent and getting old. COM, although conceptually simple, was complex in its actual coding and required lots of ugly, inelegant plumbing.
Another shortcoming of all these programming technologies was that they were aimed primarily at developing code for the desktop rather than the Internet. At the time, programming for the Web was an afterthought and seemed very different from coding for the desktop.
Goals for the Next-Generation Platform Services
What we really needed was a new start—an integrated, object-oriented development framework that would bring consistency and elegance back to programming. To meet this need, Microsoft set out to develop a code execution environment and a code development environment that met these goals. Figure 1-1 lists these goals.
Figure 1-1. Goals for the next-generation platform
Enter Microsoft .NET
In 2002, Microsoft released the first version of the .NET Framework, which promised to address the old problems and meet the goals for the next-generation systems. The .NET Framework is a much more consistent and object-oriented environment than either the MFC or COM programming technologies Some of its features include the following:
____________
1 I was once interviewed for a contract C# position when the Human Resources interviewer asked me how much experience I'd had programming in “see pound” (instead of “see sharp”)! It took me a moment to realize what he was talking about.
- Multiple platforms: The system runs on a broad range of computers, from servers and desktop machines to PDAs and cell phones.
- Industry standards: The system uses industry-standard communication protocols, such as XML, HTTP, SOAP, JSON, and WSDL.
- Security: The system can provide a much safer execution environment, even in the presence of code obtained from suspect sources.
Components of the .NET Framework
The .NET Framework consists of three components, as shown in Figure 1-2. The execution environment is called the Common Language Runtime (CLR). The CLR manages program execution at run time, including the following:
- Memory management and garbage collection
- Code safety verification
- Code execution, thread management, and exception handling
The programming tools include everything you need for coding and debugging, including the following:
- The Visual Studio integrated development environment (IDE)
- .NET-compliant compilers (e.g., C#, Visual Basic .NET, F#, IronRuby, and managed C++)
- Debuggers
- Web development server-side technologies, such as ASP.NET and WCF
The Base Class Library (BCL) is a large class library used by the .NET Framework and available for you to use in your programs as well.
Figure 1-2. Components of the .NET Framework
An Improved Programming Environment
The .NET Framework offers programmers considerable improvements over previous Windows programming environments. The following sections give a brief overview of its features and their benefits.
Object-Oriented Development Environment
The CLR, the BCL, and C# are designed to be thoroughly object-oriented and act as a well-integrated environment.
The system provides a consistent, object-oriented model of programming for both local programs and distributed systems. It also provides a software development interface for desktop application programming, mobile application programming, and web development, consistent across a broad range of targets, from servers to cell phones.
Automatic Garbage Collection
The CLR has a service called the garbage collector (GC), which automatically manages memory for you.
- The GC automatically removes objects from memory that your program will no longer access.
The GC relieves programmers of tasks they have traditionally had to perform, such as deallocating memory and hunting for memory leaks. This is a huge improvement, since hunting for memory leaks can be difficult and time-consuming.
Interoperability
The .NET Framework was designed for interoperability between different .NET languages, the operating system or Win32 DLLs, and COM.
- The .NET language interoperability allows software modules written using different .NET languages to interact seamlessly.
- A program written in one .NET language can use and even inherit from a class written in another .NET language, as long as certain rules are followed.
- Because of its ability to easily integrate modules produced in different programming languages, the .NET Framework is sometimes described as language-agnostic.
- The .NET Framework provides a feature called platform invoke (P/Invoke), which allows code written for .NET to call and use code not written for .NET. It can use raw C functions imported from standard Win32 DLLs, such as the Windows APIs.
- The .NET Framework also allows interoperability with COM. .NET Framework software components can call COM components, and COM components can call .NET components as if they were COM components themselves.
No COM Required
The .NET Framework frees the programmer from the COM legacy. If you’re coming from a COM programming environment you’ll be happy to know that, as a C# programmer, you don’t need to use any of the following:
- The
IUnknowninterface: In COM, all objects must implement interfaceIUnknown. In contrast, all .NET objects derive from a single class calledobject. Interface programming is still an important part of .NET, but it’s no longer the central theme.- Type libraries: In COM, type information is kept in type libraries as
.tlbfiles, which are separate from the executable code. In .NET, a program’s type information is kept bundled with the code in the program file.- Manual reference counting: In COM, the programmer had to keep track of the number of references to an object to make sure it wasn’t deleted at the wrong time. In .NET, the GC keeps track of references and removes objects only when appropriate.
HRESULT: COM used theHRESULTdata type to return runtime error codes. .NET doesn’t useHRESULTs. Instead, all unexpected runtime errors produce exceptions.- The registry: COM applications had to be registered in the system registry, which holds information about the configurations of the operating system and applications. .NET applications don’t need to use the registry. This simplifies the installation and removal of programs. (However, there is something similar called the global assembly cache, which I’ll cover in Chapter 21.)
Although the amount of COM code that’s currently being written is fairly small, there’s still quite a number of COM components in systems currently being used, and C# programmers sometimes need to write code that interfaces with those components. C# 4.0 introduced several new features that make that task easier. These features are covered in Chapter 25.
Simplified Deployment
Deploying programs written for the .NET Framework can be much easier than it was before, for the following reasons:
- The fact that .NET programs don’t need to be registered with the registry means that in the simplest case, a program just needs to be copied to the target machine and it’s ready to run.
- .NET offers a feature called side-by-side execution, which allows different versions of a DLL to exist on the same machine. This means that every executable can have access to the version of the DLL for which it was built.
Type Safety
The CLR checks and ensures the type safety of parameters and other data objects—even between components written in different programming languages.
The Base Class Library
The .NET Framework supplies an extensive base class library, called, not surprisingly, the Base Class Library (BCL). (It’s also sometimes called the Framework Class Library [FCL]). You can use this extensive set of available code when writing your own programs. Some of the categories are the following:
- General base classes: Classes that provide you with an extremely powerful set of tools for a wide range of programming tasks, such as file manipulation, string manipulation, security, and encryption
- Collection classes: Classes that implement lists, dictionaries, hash tables, and bit arrays
- Threading and synchronization classes: Classes for building multithreaded programs
- XML classes: Classes for creating, reading, and manipulating XML documents
Compiling to the Common Intermediate Language
The compiler for a .NET language takes a source code file and produces an output file called an assembly. Figure 1-3 illustrates the process.
- An assembly is either an executable or a DLL.
- The code in an assembly isn’t native machine code but an intermediate language called the Common Intermediate Language (CIL).
- An assembly, among other things, contains the following items:
- The program’s CIL
- Metadata about the types used in the program
- Metadata about references to other assemblies
Figure 1-3. The compilation process
Note The acronym for the intermediate language has changed over time, and different references use different terms. Two other terms for the CIL that you might encounter are Intermediate Language (IL) and Microsoft Intermediate Language (MSIL). These terms were frequently used during .NET’s initial development and early documentation, although they’re used much less frequently now.
Compiling to Native Code and Execution
The program’s CIL isn’t compiled to native machine code until it’s called to run. At run time, the CLR performs the following steps, as shown in Figure 1-4:
- It checks the assembly’s security characteristics.
- It allocates space in memory.
- It sends the assembly’s executable code to the just-in-time (JIT) compiler, which compiles portions of it to native code.
The executable code in the assembly is compiled by the JIT compiler only as it’s needed. It’s then cached, in case it’s needed for execution again later in the program. Using this process means that code that isn’t called during execution isn’t compiled to native code, and code that is called need only be compiled once.
Figure 1-4. Compilation to native code occurs at run time.
Once the CIL is compiled to native code, the CLR manages it as it runs, performing such tasks as releasing orphaned memory, checking array bounds, checking parameter types, and managing exceptions. This brings up two important terms:
- Managed code: Code written for the .NET Framework is called managed code and needs the CLR.
- Unmanaged code: Code that doesn’t run under the control of the CLR, such as Win32 C and C++ DLLs, is called unmanaged code.
Microsoft also supplies a tool called the Native Image Generator, or Ngen, which takes an assembly and produces native code for the current processor. Code that’s been run through Ngen avoids the JIT compilation process at run time.
Overview of Compilation and Execution
The same compilation and execution process is followed regardless of the language of the original source files. Figure 1-5 illustrates the entire compilation and runtime processes for three programs written in different languages.
Figure 1-5. Overview of the compile-time and runtime processes
The Common Language Runtime
The core component of the .NET Framework is the CLR, which sits on top of the operating system and manages program execution, as shown in Figure 1-6. The CLR also provides the following services:
- Automatic garbage collection
- Security and authentication
- Extensive programming functionality through access to the BCL—including functionality such as web services and data services
Figure 1-6. Overview of the CLR
The Common Language Infrastructure
Every programming language has a set of intrinsic types representing such objects as integers, floating-point numbers, characters, and so on. Historically, the characteristics of these types have varied from one programming language to another and from platform to platform. For example, the number of bits constituting an integer has varied widely depending on the language and platform.
This lack of uniformity, however, makes it difficult if we want programs to play well with other programs and libraries written in different languages. To have order and cooperation, there must be a set of standards.
The Common Language Infrastructure (CLI) is a set of standards that ties all the components of the .NET Framework into a cohesive, consistent system. It lays out the concepts and architecture of the system and specifies the rules and conventions to which all the software must adhere. Figure 1-7 shows the components of the CLI.
Figure 1-7. Components of the CLI
Both the CLI and C# have been approved as open international standard specifications by Ecma International. (The name “Ecma” used to be an acronym for the European Computer Manufacturers Association, but it’s now just a word in itself.) Ecma members include Microsoft, IBM, Hewlett-Packard, Adobe, and many other corporations associated with computers and consumer electronics.
Important Parts of the CLI
Although most programmers don’t need to know the details of the CLI specifications, you should at least be familiar with the meaning and purpose of the Common Type System (CTS) and the Common Language Specification (CLS).
The Common Type System
The CTS defines the characteristics of the types that must be used in managed code. Some important aspects of the CTS are the following:
- The CTS defines a rich set of intrinsic types, with fixed, specific characteristics for each type.
- The types provided by a .NET-compliant programming language generally map to some specific subset of this defined set of intrinsic types.
- One of the most important characteristics of the CTS is that all types are derived from a common base class—called
object.- Using the CTS ensures that the system types and types defined by the user can be used by any .NET-compliant language.
The Common Language Specification
The CLS specifies the rules, properties, and behaviors of a .NET-compliant programming language. The topics include data types, class construction, and parameter passing.
Review of the Acronyms
This chapter has covered a lot of .NET acronyms, so Figure 1-8 will help you keep them straight.
Figure 1-8. The .NET acronyms
The Evolution of C#
The current version of the language is version 5.0. Each new release of the language has had a specific focus for the new features added. The focus of the new features in version 5.0 is asynchronous programming. I’ll cover these features extensively in Chapter 20.
Figure 1-9 shows the main feature focus for each of the releases of the language and the chapter in which that material is covered.
Figure 1-9. The focuses of the feature sets for the releases of C#