VB.NET 2005 Training : The .NET Framework Architecture Part 1

This is the first tutorial as part of the Visual Basic .NET 2005 Training. In this tutorials we will be learning about the basics of The .NET Framework Architecture, The .NET vision, Common Language Runtime (CLR), .NET Framework Class Library and Microsoft Intermediate Language (MSIL). It's very important to learn the basics before we actually start with the Programming.
The .NET Vision

The .NET framework is a software technology that is directed towards connecting information, people, systems and devices seamlessly. The high level of software integration that has been attempted through use of XML web services enables the creation of small, discrete, building block types of applications. These applications are connected to other applications over the Internet.
Central to the .NET framework architecture is the effort to provide support to for the next generation solutions. The direction of change is to ensure that software deployment and versioning conflicts are avoided or minimized in the .NET Framework. User defined codes are released from the confines of the local storage systems and can be stored anywhere on a network and executed from any point in the network. Performance problems associated with scripted and interpreted environments are removed. Codes can be safely executed and the developer experience is consistent across widely varying types of applications, such as Windows based applications and web based applications. The thrust of design is towards creating a standard communication facility that is standardized so that .NET codes can be integrated with other codes easily and seamlessly.
At the core of the .NET infrastructure is the Common Language Runtime (CLR) and the .NET Framework class library.
The runtime functions, like an agent, managing code at execution time. It provides core services such as memory management, thread management and ‘remoting’. It enforces strict type safety and ensures code accuracy. This makes for security and robustness and provides a platform for running managed code.
The .NET Framework provides several runtime hosts. It also supports the development of third-party runtime hosts. For example, ASP.NET hosts the runtime to provide a scalable, server-side environment for managed code. ASP.NET works directly with the runtime to enable ASP.NET applications and XML Web services.
The .NET Framework can be hosted by unmanaged components such as the Internet Explorer. These load the common language runtime into their processes and initiate the execution of managed code. This creates a software environment that can exploit both managed and unmanaged features. This makes for mobility of the code.
Common Language Runtime (CLR)
The common language runtime (CLR) is the foundation upon which developers construct various kinds of applications. The benefits of the CLR are many. It makes for a vastly simplified development. It enables a seamless integration of code written in different languages. It provides evidence-based security with code identity. The assembly based deployment eliminates the problems of DLL. The versioning of reusable components makes for ease of usage. The implementation inheritance feature enables the reuse of code. The automatic object lifetime management makes the application- development comfortable. The self descriptive nature of objects makes for ease of programming and debugging.

CLR includes both private and shared components. It provides for incremental download of code and caching; native platform interoperability and seamless integration with COM. It offers dynamic inspection capabilities, administration and configuration options. The developer is not required to know all the runtime supported infrastructure. The tools and frameworks are designed to expose a subset of the functionality in accordance with the kind of application being built.
The common language runtime is a virtual execution system that provides important services such as memory management, security and also has a Just-in-Time compiler (JIT) which converts the intermediate language (IL) into native code that can be executed by the physical machine. The infrastructure provides a machine independent environment for application execution.
VB.NET 2005 Free Training : The .NET Framework Architecture Part 2. In this tutorial of The .NET Framework Architecture Part 2 we will learn about Just-In-Time (JIT) compilation, Assemblies, native assemblies, Global Assembly Cache (GAC) and Comparison of VB.NET, C#, and J#.
Just-In-Time (JIT) compilation
As stated above, the Just in time compiler is a facility that is invoked by the CLR to convert the IL into machine code. The .NET framework assemblies (*.dll or *.exe) files cannot be executed by the target processor unless it is converted into native code. When the Assembly is loaded the method calls are invoked for compilation into native code. Since this is done just when the method needs to execute, it is called Just in time compilation. When the JIT is invoked for the first time there is an overhead or performance penalty, since the assembly is converted into its Native code or image using the Native Image Generator (Ngen.exe). All subsequent calls will load faster as the Native image alone is invoked thereafter from the Native image cache.
Significantly, the IL can coexist with the machine code in the application. This feature also enables the developer modify the code or add to the code even when the application is actively deployed. This functionality provided by JIT makes the .NET framework an efficient, agile and powerful means of application development.
Assemblies, native assemblies, and the Global Assembly Cache (GAC)
The primary unit of deployment is the assembly. The assembly is used by the .NET CLR as the smallest unit of deployment; version control; security; type grouping and code reuse. An assembly will consist of a manifest and one or more modules or files. It can be defined as a logical DLL that contains a manifest, type metadata, MSIL and resources. Assemblies can be application private or shared. Private assemblies are restricted to use in a single application whereas shared assemblies can be used across applications. Private applications also reside within the application folder while shared assemblies reside in the common area-- GAC(Global Assembly Cache). They must have a globally unique name.
The existence of the manifest within the assembly makes it self descriptive. It can be viewed by the IL Disassembler (Ildasm.exe) which is part of the .NET framework SDK.
The assembly is identified by the manifest. It defines security requirements, lists other interdependent assemblies and all the types and resources exposed by the assembly. Localized resources exposed by assemblies and targeted by the application contain a default culture (language, currency, date/time format etc).
The manifest contains several sections. Identity, Referenced Assemblies, file list and Custom Attributes are some of the important sections of the manifest. The Identity section as the name suggests, identifies the assembly. It contains a .assembly directive. The version directive specifies the version of the assembly, so that the CLR identifies the different versions of an application. The Identity section contains a strong name for shared assemblies and a public/private encryption key is used to distinguish between assemblies of the same name. The Identity section also optionally contains the Culture which defines the country and language of the assembly target. The .locale directive is used for this purpose and the Culture-Neutral assemblies can be used by any assembly. The Referenced Assemblies section of the manifest provides a reference to all the assemblies used in an application.
Comparison of VB.NET, C#, and J#

The .NET framework architecture has made the language of coding immaterial to the final output. All languages also have equal access to all development capabilities and revolve around the .NET classes. The language syntax, operations etc look similar in all the languages of this group. Moreover, code can be shared by all .NET languages and so a class made in C# or J# can be used in VB.NET and vice versa.
In this context choice of language is no longer significant. Finally, all languages are transformed by the compiler into Microsoft Intermediate language. It is the programmer’s familiarity with the language that makes it material whether he is coding in VB.NET or C# or J#. However, the option settings in the compiler will have to be set to the language of coding before the compiler is used.
The speed of performance of the compiler will also vary with the language being compiled. For instance C# compiles faster than VB.NET. Subject to the above observation, the features of the languages will be dicussed in the next tutorial.