.NET Architecture
You’ll find that we emphasize throughout this book that the C# language cannot be viewed in isolation,but must be considered in parallel with the .NET Framework. The C# compiler specifically
targets .NET, which means that all code written in C# will always run within the .NET Framework.
This has two important consequences for the C# language:
❑ The architecture and methodologies of C# reflect the underlying methodologies of .NET.
❑ In many cases, specific language features of C# actually depend upon features of .NET, or of the .NET base classes.
Because of this dependence, it is important to gain some understanding of the architecture and
methodology of .NET before we begin C# programming. That is the purpose of this chapter.
We will begin by going over what happens when all code (including C#) that targets .NET is compiled
and run. Once we have this broad overview, we will take a more detailed look at the
Microsoft Intermediate Language (MSIL or simply IL), the assembly language which all compiled
code ends up in on .NET. In particular, we will see how IL, in partnership with the Common Type
System (CTS) and Common Language Specification (CLS) works to give us interoperability between
languages that target .NET. We’ll also discuss where common languages (including Visual Basic
and C++) fit into .NET.
Once we’ve done that, we will move on to examine some of the other features of .NET, including
assemblies, namespaces, and the .NET base classes. We’ll finish the chapter with a brief look at the
kinds of applications we can create as C# developers.
The Relationship of C# to .NET
C# is a relatively new programming language, and is significant in two respects:
❑ It is specifically designed and targeted for use with Microsoft’s .NET Framework (a feature-rich
platform for the development, deployment, and execution of distributed applications).
❑ It is a language based on the modern object-oriented design methodology, and when designing
it Microsoft has been able to learn from the experience of all the other similar languages that
have been around since object-oriented principles came to prominence some 20 years ago.
One important thing to make clear is that C# is a language in its own right. Although it is designed to
generate code that targets the .NET environment, it is not itself part of .NET. There are some features
that are supported by .NET but not by C#, and you might be surprised to learn that there are actually
features of the C# language that are not supported by .NET (for example, some instances of operator
overloading)!
However, since the C# language is intended for use with .NET, it is important for us to have an understanding
of this Framework if we want to develop applications in C# effectively. So, in this chapter we’re
going to take some time to peek underneath the surface of .NET. Let’s get started.
The Common Language Runtime
Central to the .NET Framework is its runtime execution environment, known as the Common Language
Runtime (CLR) or the .NET runtime. Code running under the control of the CLR is often termed managed
code.
However, before it can be executed by the CLR, any source code that we develop (in C# or some other
language) needs to be compiled. Compilation occurs in two steps in .NET:
1. Compilation of source code to IL
2. Compilation of IL to platform-specific code by the CLR
This two-stage compilation process is very important, because the existence of the IL (managed code) is
the key to providing many of the benefits of .NET. Let’s see why.
Advantages of Managed Code
Microsoft intermediate language shares with Java byte code the idea that it is a low-level language with
a simple syntax (based on numeric codes rather than text), which can be very quickly translated into
native machine code. Having this well-defined universal syntax for code has significant advantages.
Platform independence
First, it means that the same file containing byte code instructions can be placed on any platform; at
runtime the final stage of compilation can then be easily accomplished so that the code will run on that
particular platform. In other words, by compiling to IL we obtain platform independence for .NET, in
much the same way as compiling to Java byte code gives Java platform independence.
You should note that the platform independence of .NET is only theoretical at present because, at the
time of writing, a complete implementation of .NET is only available for Windows. However, there is a
partial implementation available (see for example the Mono project, an effort to create an open source
implementation of .NET, at www.go-mono.com/).
Performance improvement
Although we previously made comparisons with Java, IL is actually a bit more ambitious than Java byte
code. IL is always Just-In-Time compiled (known as JIT compilation), whereas Java byte code was often
interpreted. One of the disadvantages of Java was that, on execution, the process of translating from Java
byte code to native executable resulted in a loss of performance (with the exception of more recent cases,
where Java is JIT compiled on certain platforms).
Instead of compiling the entire application in one go (which could lead to a slow start-up time), the JIT
compiler simply compiles each portion of code as it is called (just-in-time). When code has been compiled
once, the resultant native executable is stored until the application exits, so that it does not need to be
recompiled the next time that portion of code is run. Microsoft argues that this process is more efficient
than compiling the entire application code at the start, because of the likelihood that large portions of any
application code will not actually be executed in any given run. Using the JIT compiler, such code will
never be compiled.
This explains why we can expect that execution of managed IL code will be almost as fast as executing
native machine code. What it doesn’t explain is why Microsoft expects that we will get a performance
improvement. The reason given for this is that, since the final stage of compilation takes place at runtime,
the JIT compiler will know exactly what processor type the program will run on. This means that it can
optimize the final executable code to take advantage of any features or particular machine code instructions
offered by that particular processor.
Traditional compilers will optimize the code, but they can only perform optimizations that are independent
of the particular processor that the code will run on. This is because traditional compilers compile
to native executable before the software is shipped. This means that the compiler doesn’t know what
type of processor the code will run on beyond basic generalities, such as that it will be an x86-compatible
processor or an Alpha processor. Visual Studio 6, for example, optimizes for a generic Pentium machine,
so the code that it generates cannot take advantage of hardware features of Pentium III processors. On
the other hand, the JIT compiler can do all the optimizations that Visual Studio 6 can, and in addition it
will optimize for the particular processor the code is running on.
Language interoperability
The use of IL not only enables platform independence; it also facilitates language interoperability. Simply
put, you can compile to IL from one language, and this compiled code should then be interoperable with
code that has been compiled to IL from another language.
You’re probably now wondering which languages aside from C# are interoperable with .NET, so let’s
briefly discuss how some of the other common languages fit into .NET.
Visual J# .NET
The latest language to be added to the mix is Visual J# .NET. Prior to .NET Framework 1.1, users were
able to use J# only after making a separate download. Now the J# language is built into the .NET
Framework. Because of this, J# users are able to take advantage of all the usual features of Visual Studio
.NET. Microsoft expects that most J++ users will find it easiest to use J# if they want to work with .NET.
Instead of being targeted at the Java runtime libraries, J# uses the same base class libraries that the rest
of the .NET compliant languages use. This means that you can use J# for building ASP.NET Web applications,
Windows Forms, XMLWeb services, and everything else that is possible—just as C# and Visual
Basic .NET can.
Scripting languages
Scripting languages are still around, although, in general, their importance is likely to decline with the
advent of .NET. JScript, on the other hand, has been upgraded to JScript .NET. We can now write ASP.NET
pages in JScript .NET, run JScript .NET as a compiled rather than an interpreted language, and write
strongly typed JScript .NET code. With ASP.NET there is no reason to use scripting languages in serverside
Web pages. VBA is, however, still used as a language for Microsoft Office and Visual Studio macros.
COM and COM+
Technically speaking, COM and COM+ aren’t technologies targeted at .NET, because components based
on them cannot be compiled into IL (although it’s possible to do so to some degree using managed C++, if
the original COM component was written in C++). However, COM+ remains an important tool, because
its features are not duplicated in .NET. Also, COM components will still work—and .NET incorporates
COM interoperability features that make it possible for managed code to call up COM components and
vice versa (this is discussed in Chapter 29). In general, however, you will probably find it more convenient
for most purposes to code new components as .NET components, so that you can take advantage of the
.NET base classes as well as the other benefits of running as managed code.
Sursa
2007-07-14 19:42:00