Architecture of .Net Framework

Architecture of the . NET Framework Chapter 1 The . NET Framework development platform introduces many new concepts, technologies, and terms. The goal of this chapter is to give an overview of the .

NET Framework: to show how it is architected, to introduce some of the new technologies, and to define many of the new terms. I'll also take you through the process of building your source code into an application or a set of redistributable components (types), and then explain how these components execute. Compiling Source Code into Managed Modules 0K, so youVe decided to use the .NET Framework as your development platform. Great! Your first step is to determine what type of application or component you intend to build.

Let's Just assume that youVe handled this minor detail, everything is designed, the specifications are written, and you're ready to start development. Next, you must decide what programming language to use. This is usually a difficult task because different languages offer different capabilities. For example, in unmanaged C/C++, you have pretty low-level control of the system. You can manage memory exactly the way you want to, create threads easily if you need to, and so on.Visual Basic 6, on the other hand, allows you to build Ul applications very rapidly and allows the easy control of COM objects and databases.

If you use the . NET Framework, your code targets the common language runtime (CLR), which affects your decision about a programming language. The common language runtime is Just what its name says it is: A runtime that is usable by different and varied programming languages. The features of the CLR are available to any and all programming languages that target it- period.

If the runtime uses exceptions to report errors, then all languages get errors reported via exceptions.If the runtime allows you to create a thread, then any language can create a thread. In fact, at runtime, the CLR has no idea which programming language the developer used for the source code. This means that you should choose whatever programming language allows you to express your intentions most easily. You may develop your code in any programming language you desire as long as the compiler you use to compile your code targets the CLR.

So if what I say is true, then what is the advantage of using one programming language over another? Well, I think of compilers as syntax checkers and "correct code" nalyzers.They examine your source code, ensure that whatever youVe written makes some sense, and then output code that describes your intention. Simply put, different programming languages allow you to develop using different syntax. Don't underestimate the value of this. For mathematical or financial applications, expressing your intentions using APL syntax can save many days of development time when compared to expressing the same intention using Perl syntax, for example.

managed extensions, C# (pronounced "C sharp"), Visual Basic. NET, JScript, Java, and an intermediate language (IL) Assembler.In addition to Microsoft, there are several other companies creating compilers that produce code that targets the CLR. At this writing, I am aware of compilers for Alice, APL, COBOL, Component Pascal, Eiffel, Fortran, Haskell, Mercury, ML, Mondrian, Oberon, Perl, Python, RPG, Scheme, and Smalltalk.

The fgure on the next page shows the process of compiling source code files: Applied . NET Framework Programming As the figure shows, you can create source code files using any programming language that supports the CLR. Then, you use the corresponding compiler to check syntax and analyze the source code.Regardless of which compiler you use, the result is a managed module.

A managed module is a standard Windows portable executable (PE) file that requires the CLR to execute. In the future, other operating systems may use the PE file format as well. A Managed Module is composed of the following parts: Part PE header Description This is the standard Windows PE file header, which is similar to the Common Object File Format (COFF) header. The PE header indicates the type of file--GUI, CU', or DLL”and also has a timestamp indicating when the file was built. For modules that contain only IL code (see below,Intermediate Language Code), the bulk of the information in the PE header is ignored.

For modules that contain native CPU code, this header contains information about the native CPU code. This header contains the information (interpreted by the CLR and utilities) that makes this a managed module. It includes the version of the CLR required, some flags, the MethodDef metadata token of the managed module's entry point method (Main method), and the location/size of the module's metadata, resources, strong name, some flags, and other less interesting stuff.Every managed module contains metadata tables, of which there are 2 main types: those that escribe the types and members defined in your source code, and those that describe the types and members referenced by your source code.

CLR header Metadata 2 Part Intermediate Language (IL) Code Description This is the code that was produced by the compiler as it compiled the Most compilers of the past produced code targeted to a specific CPU architecture, such as x86, IA64, Alpha, or PowerPC. All CLR-compliant compilers produce intermediate language (IL) code instead.IL code is sometimes referred to as managed code, because its lifetime and execution are managed by the CLR. IL code is iscussed later in this chapter.

In addition to emitting IL, every compiler targeting the CLR is required to emit full metadata into every managed module. In brief, metadata is simply a set of data tables that describe what is defined in the module, such as types and their members. In addition, metadata also has tables indicating what the managed module references, such as imported types and their members. Metadata is a superset of older technologies such as type libraries and IDL files.The important thing to note is that CLR metadata is far more complete than its predecessors. And, nlike type libraries and IDL, metadata is always associated with the file that contains the IL code.

In fact, the metadata is always embedded in the same EXE/DLL as the code, making it impossible to separate the two. Since the metadata and code are produced by the compiler at the same time and are bound into the resulting managed module, the metadata and the IL code it describes are never out of sync with one another. Metadata has many uses.Here are some of them: Metadata removes the need for header and library files when compiling, because all the information about the referenced types/members is contained in one file along ith the IL that implements those type/members. Compilers can read metadata directly from managed modules.

Visual Studio uses metadata to help you write code. Its IntelliSense feature parses metadata to tell you what methods a type offers and what parameters that method expects. The CLR code verification process uses metadata to ensure that your code performs only "safe" operations. Verification is discussed shortly.

Metadata allows an object's fields to be serialized into a memory block, remoted to another machine, and then deserialized, recreating the object and its state on the remote machine. Metadata allows the garbage collector to track the lifetime of objects. For any object, the garbage collector can determine the type of the object, and from the metadata it knows which fields within that object refer to other objects. The next chapter, "Building, Packaging, Deploying, and Administering Applications and Types," will describe metadata in much more detail. And a little later in this chapter, we'll explore intermediate language in more detail.Four of the compilers that Microsoft offers--C#, Visual Basic, JScript, and the IL Assembler--always produce managed modules, which require the CLR to execute.

That is, end users must have the CLR installed on their machines in order to execute any managed modules. This situation is similar to the one that end users face with MFC or VB 6 applications: they must have the MFC or VB DLLs installed in order to run them. The Microsoft C++ compiler, by default, builds unmanaged modules: the EXE or DLL files with which we by specifying a new command-line switch, the C++ compiler can produce managed modules that do require the CLR to execute.Of all the Microsoft compilers mentioned, C++ is unique in that it is the only language that allows the developer to rite both managed and 3 unmanaged code and have it emitted into a single managed module. This can be a great feature because it allows developers to write the bulk of their applications in managed code (for type-safety and component interoperability) but continue to access their existing unmanaged C++ code.

Combining Managed Modules into Assemblies The CLR doesn't actually work with modules; it works with assemblies. An assembly is an abstract concept, which can be difficult to grasp at first.First, an assembly is a logical grouping of one or more managed modules or resource files. Second, an ssembly is the smallest unit of reuse, security, and versioning.

Depending on the choices you make with your compilers or tools, you can produce a single-file assembly or you can produce a multi-file assembly. Chapter 2, "Building, Packaging, Deploying, and Administering Applications and Types," discusses assemblies in great detail, so I don't want to spend a lot of time on it here. All I want to do now is make you aware that there is this extra conceptual notion that offers a way to treat a group of files as a single entity.The fgure below should help explain what assemblies are about: In this figure, we are passing the file names of some managed modules and resource (or data) files to a tool. This tool produces a single PE file that represents the logical grouping of files. This PE file contains a block of data called the manifest, which is simply another set of metadata tables.

These tables describe the assembly: the files that make it up, the publicly exported types implemented by the files in the assembly, and the resource or data files that are associated with it.By default, compilers actually do the work of turning the emitted managed module into an assembly. That s, the C# compiler emits a managed module that contains a manifest. The manifest indicates that the assembly consists of Just the 4 one file. So for projects that have Just one managed module and no resource files, the assembly will be the managed module, and you don't have any additional steps to perform during your build process.

If you wish to group a set of files into an assembly, then you will have to be aware of more tools (such as the assembly linker, AL. exe) and their command-line options.These tools and options are explained in the next chapter. An assembly allows you to decouple the logical and physical notions of reusable, deployable, versionable component. The way in which you partition your code and resources into different files is completely up to you.

For example, you could separate files could be downloaded from the web as needed. If the files are never needed, they're never downloaded, saving disk space and reducing installation time. An assembly lets you break up the physical deployment of the files but still treat them as a single collection.