The C# programming language was designed for developing programs for Microsoft's .NET Framework. This chapter will take a brief look at where .NET came from, and its basic architecture. Just to make sure you're starting on the right foot, let me take this opportunity to remind you of what is hopefully the obvious: C# sharp is pronounced see sharp.[1]
In the late 1990s, Windows programming using the Microsoft platform had fractured into a number of branches. Most programmers were using Visual Basic (VB), C, or C++. Some C and C++ programmers were using the raw Win32 API, but most were using the 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.
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, which are listed in Figure 1-1.
In 2002, Microsoft released the .NET Framework, which promised to address the old problems and meet the goals for the next-generation system. 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:
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, and WSDL.
Security: The system can provide a much safer execution environment, even in the presence of code obtained from suspect sources.
The .NET Framework is made up 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
Code safety verification
Code execution
Garbage collection
The programming tools include everything you need for coding and debugging, including the following:
The Visual Studio integrated development environment
.NET-compliant compilers (e.g., C#, VB, JScript, and managed C++)
Debuggers
Server-side improvements, such as ASP.NET
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.
The .NET Framework offers programmers considerable improvements over previous Windows programming environments. A brief overview of its features and their benefits is given in the following sections.
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.
The CLR has a service called the Garbage Collector (GC), which automatically manages memory for you.
The GC automatically deletes objects from memory that your program will no longer access.
The GC relieves the programmer of tasks that he or she has traditionally had to perform, such as deallocating memory and hunting for memory leaks. This is no small feature, since hunting for memory leaks can be difficult and time-consuming.
The .NET Framework was designed for interoperability between different .NET languages, the operating system or Win32 DLLs, and COM.
.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.
.NET provides a feature called platform invoke (P/Invoke), which allows code written for .NET to call and use code not written for .NET but exported as raw C functions by standard Win32 DLLs, such as the Windows APIs.
The .NET Framework also allows interoperability with COM..NET software components can call COM components and COM components can call .NET components as if they were COM components themselves.
The .NET Framework frees the programmer from the COM legacy. As a C# programmer, you do not need to use COM, and therefore do not need 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 is 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 together with the code in the program file.Reference counting: In COM, the programmer must keep track of the number of references to an object to make sure it is not deleted at the wrong time. In .NET, the GC keeps track of references and deletes objects only when appropriate.
HRESULT: COM uses theHRESULTdata type to return runtime error codes..NET does not useHRESULTs. Instead, all unexpected runtime errors produce exceptions.The registry: COM applications must be registered in the system registry, which holds information about the configurations of the operating system and applications. .NET applications do not use the registry—simplifying the installation and removal of programs. (Although there is something similar called the Global Assembly Cache, which I'll cover in Chapter 10.)
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.
The CLR checks and ensures the type safety of parameters and other data objects—even between components written in different programming languages.
The .NET Framework supplies an extensive base class library, called, not surprisingly, the Base Class Library (BCL). (It is 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 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
The compiler for a .NET language takes a source code file and produces an output file called an assembly. An assembly is either an executable or a DLL. The process is illustrated in Figure 1-3.
The code in an assembly is not native machine code, but an intermediate language called the Common Intermediate Language (CIL).
An assembly, among other things, contains the following items:
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 IL (Intermediate Language) and MSIL (Microsoft Intermediate Language), which was used during initial development andearly documentation.
The program's CIL is not compiled to native machine code until it is 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 as it is needed. It is then cached in case it is needed for execution again later in the program. Using this process means that code that isn't called isn't compiled to native code, and code that is called is only compiled once.
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:
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 has been run through Ngen avoids the JIT compilation process at run time.
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.
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
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. The components of the CLI are illustrated in Figure 1-7.
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.
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 and the Common Language Specification.
The Common Type System (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.
This chapter has covered a lot of .NET acronyms, so Figure 1-8 is included to help you keep them straight.
[1] I was once interviewing for a contract C# programming 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.