Namespaces - Page 8

One of the most important concepts in .NET is namespaces. They help organize object libraries and hierarchies, simplify object references, prevent ambiguity when referring to objects, and control the scope of object identifiers.

Namespaces are discussed in more detail in Chapter 6. For now, it is useful to know that class libraries are normally referenced in each language before they are used. The reference allows the types to be used in the code with abbreviations instead of detailed library references. In VB, this is done with an Imports statement, and that this can be thought of as similar in concept to checking a box in the References dialog in Visual Basic 6. For example, a typical VB form module in .NET might have the following lines at the beginning:

Imports System.WinForms
Imports MyDebug = System.Diagnostics.Debug

The first line simply makes all of the standard form properties and methods available to the code in the form module. This second line illustrates use of an alias. A branch of the object hierarchy can thus receive its own identifier, which is only valid in that code module. Instead of referring to the System.Diagnostics.Debug class object, the code in this module would refer to the MyDebug object.

Deployment and Execution

With all the intelligence in the .NET framework, there is a lot more going on at execution time with the CLR than we are accustomed to. Programs or components can't just load and go – there are several things that must happen for the whole structure to work.

Start with an Assembly, Build to an Application

The unit of deployment, as previously mentioned, is an assembly. It can consist of one or more files and is self-describing. It contains a "manifest" which holds the metadata describing everything exported from the assembly, and what's needed to deploy and run the assembly.

An assembly has its own version. Assemblies are combined to become applications. An application has one or more assemblies, and also may contain application specific files or data. Applications may have their own private versions of assemblies, and may be configured to prefer their private version to any shared versions.

Execution

Source code modules for an assembly are compiled (at development time) into the CLR's Intermediate Language (IL). Then IL is compiled into native code before execution. That compilation can take place in several ways, and at various times. Normally, however, compilation into native code is done only once and the results are cached for future use.

The CLR contains a couple of just-in-time (JIT) compilers, which convert IL to native code (binary code targeted at a specific machine processor). One is called "Econo-JIT" and it has very fast compilation, but produces un-optimized code. It is useful when the code, such as script in a batch file, will likely be thrown away and regenerated. The other is the standard JIT compiler, which operates a bit more slowly but performs a high level of optimization. It is used for most systems.

The JIT compilers produce code that is targeted at the specific processor on the machine. This is one of the reasons applications in .NET would normally be distributed in compiled IL, allowing processor-specific optimizations in native code to be done by the .NET compilers on a particular machine. An installation of a package can be set to pre-compile the IL code into native code during the installation if required.

Scripting also fits into this model, actually being compiled before it is used. In current systems interpreted script (in Active Server Pages or the Windows Scripting Host, for example) is never compiled. But in .NET, such script is sent through a language compiler the first time it is accessed, and transformed into IL. Then the IL is immediately transformed into native code, and cached for future use. Scripts are created in .NET the way they are now, with any editor you like, and require no explicit compilation step. The compilation is handled in the background, and is managed automatically so that a change to the script results in appropriate recompilation. VBScript developers are now encouraged to migrate to Visual Basic for web development, which is now the default language for producing ASP.NET pages.

With software compiled into a processor-independent intermediate language, .NET makes it possible to achieve future platform independence. It is architecturally possible for a CLR to be produced for platforms based on other processors or other operating systems, which would enable applications produced on Windows 2000 to run on them. Microsoft has not emphasized this in their announcements, but the capabilities of the CLR parallel in some respects those of the Java virtual machine, which is designed for platform independence.

Metadata - Page 7
Introducing .NET
The Next Layer – .NET Framework Base Classes - Page 9