Photography
, a Windows Forms application, a Web Service, a mobile code application, a distributed application, or an application that combines several of these application models, the CLR provides the following benefits for application developers: - Vastly simplified development
- Seamless integration of code written in various languages
- Evidence-based security with code identity
- Assembly-based deployment that eliminates DLL Hell
- Side-by-side versioning of reusable components
- Code reuse through implementation inheritance
- Automatic object lifetime management
- Self describing objects
From an application developer's perspective, the CLR has much to offer. The Application Infrastructure Overview describes the surfaces of the runtime that application developers come in contact with. This includes private and shared components, incremental code download and caching, native platform interoperability, seamless integration with COM, dynamic inspection (reflection), administration, configuration. In general, an application developer needn't know about all of the runtime-supported infrastructure, as the tools and frameworks will expose a subset of functionality appropriate to the type of application being built. However, architects and developers who work with a range of tools and application models will benefit from understanding the infrastructure landscape.
The CLR is a multi-language execution environment. There are currently over 15 compilers being built by Microsoft and other companies that produce code that will execute in the CLR. The CLR Compiler Writers Overview provides information for compiler writers interested in learning about the IL instruction set, file formats, metadata APIs, reflection emit, and other tools.
In addition to compilers, other tools developers can find information in the CLR Tool Developers Overview
2. Introduction
Microsoft .NET framework brings one of the amazing aspects of development, called "Cross-Language Development". By Cross-Language development it means, cross language Inheritance, Cross-Language Debugging and Cross-Language Exception handling. More generally, we can visualize Cross-Language development as follows. The code written using C# (as a matter of fact any .NET compliant language) should be usable in another language such as VB. Later on these two code modules should be usable in, yet another language like JScript etc and so on. In order to make the above said statement possible there should be a common run time environment, which can understand all these languages.
This article introduces the Cross-Language capabilities of CLR (Common Language Runtime Environment) and describes how IL (Intermediate Language) becomes core of all .NET compliant languages. In particular, I discuss about how to program using Intermediate Language and Use ILASM (IL assembler). Further, I also deal with some examples, which demonstrate the cross language capabilities of .NET framework. In the examples that follow i will be using IL (Intermediate Language), C#, Jscript, C++ and VB languages.
One of the main design goals of .NET is to encourage cross - Language development. (Cross - Language Inheritance, Exception handling etc.) The advantage of doing so is, a developer can choose a language that best suits for delivering a given module / unit (each language has its own strengths) and still be able to integrate into a single application. The end result of that is Languages become equal. Even employers also feel more comfortable as they would have more resource and options at hand.
Microsoft .NET framework also eliminates DLL hell and allows for side by side deployment of Components. This is so because registration information and state data are no longer stored in the registry where it can be difficult to establish and maintain.
In the section that follows, i will introduce the .NET framework architecture in brief and then move to different cross language implementation using different .NET compliant languages.
3. Microsoft .NET Architecture
IL - Intermediate Language
CLR Environment - Common Language runtime Environment
JIT - Just in time Compilation
VES - Virtual Execution System
BCL - Base Class Library
PE Portable Executable
GC Garbage Collector
Common Language Runtime
Common Language Runtime (CLR) manages the execution of code and provides different services like Garbage collection and support for Base Class Libraries etc. The main constituents of CLR are described below
The common Language Runtime (CLR) a rich set of features for cross-language development and deployment. CLR supports both Object Oriented Languages as well as procedural languages. CLR provides security, garbage collection, cross language exception handling, cross language inheritance and so on.
The Common Type System, support both Object Oriented Programming languages as well as procedural languages. Basically CTS provides rich type system that is intended to support wide range of languages.
CLS (Common Language Specification) defines a subset of Common Type System, which all language compilers targeting CLR must adhere to. CLS is a subset of CTS.
All compilers under .NET will generate Intermediate Language no matter what language is used to develop an application. In fact, CLR will not be aware of the language used to develop an application. All language compilers will generate a uniform, common language called Intermediate Language. For this reason IL can be called as The language of
Just in Time Compiler converts the IL code back to a platform/device specific code. In .NET you have three types of JIT compilers.
Pre-JIT (Compiles entire code into native code at one stretch)
Ecno-JIT (Compiles code part by part freeing when required)
Normal JIT (Compiles only that part of code when called and places in cache)
Type safety is ensured in this phase. In all, the role of a JIT compiler is to bring higher performance by placing the once compiled code in cache, so that when a next call is made to the same method/procedure it get executed at faster speed.
OVERVIEW
Microsoft's .NET is a broad family of products representing the company's next generation of services, software, and development tools. At the core of the .NET strategy lives the Common Language Runtime. The CLR is a platform for software development that provides services by consuming metadata. It is standards-based and component-oriented. Like any platform, the important pieces are the runtime, the libraries that provide access to them, and the languages that can target the platform.
The aim of this tutorial is to provide a foundation for forming and answering questions about the technical aspects of the CLR. We will examine this technology at a high level, defining and touching on each of the core aspects - runtime, libraries, and languages - in turn. Additionally, we'll look at the extensive support the CLR gives to standards-based and component-oriented software development.
We'll start with a broad overview of the CLR - what are the major pieces, what was the motivation for moving to this new model, and what benefits it provides. Then we'll dive down to cover some aspects of the CLR in greater depth. References to sources for further, more detailed study will be given throughout.
Note that although every effort was made to ensure that the information contained within this document was accurate at the time of publication, the technologies mentioned here are subject to change. Caveat emptor!
CLR BASICS
The Common Language Runtime is the core of Microsoft's .NET vision.
The .NET vision was officially introduced at the Microsoft Professional Developer's conference in
In keeping with their tradition of defining vague marketing terms (think ActiveX - did anyone ever figure out exactly what that meant?), the moniker ".NET" has been applied to everything from the next version of the Windows operating system to development tools. It's only half a joke to suggest that we will soon see "Age of Empires.NET" hit the shelves of computer gaming stores.
This effort on Microsoft's part to frame everything from mice to FoxPro in terms of .NET is actually a good sign: it indicates to consumers such as you and me that Microsoft is serious about the product, that it represents both a core part of their strategy, and that they are making a fundamental and massive shift. In the same way that they did with COM in the mid 1990s and with the Internet in later years, Microsoft is (in their own words) "betting the company" on this new technology.
But what exactly is .NET? Although the precise meaning can be a little hard to isolate by reading the prolific marketing literature, a little digging reveals that .NET is in fact Microsoft's grand strategy for how all of their software, systems, and services will fit together. It includes development tools (like the new version of Visual Studio, dubbed Visual Studio.NET), future versions of their Windows operating systems, new Internet-based services (like a stepped-up version of their Passport web authentication service), and an entirely new beast called the Common Language Runtime.
The Common Language Runtime is the single most important piece of the .NET product strategy, because it is in essence the engine that pulls the train - the CLR is how developers will write software in the brave new .NET world (see figure 1). For that reason, this tutorial will focus on the CLR exclusively. For information about other .NET technologies, such as HailStorm (a set of web-enabled services based around Microsoft's Passport technology), Visual Studio.NET, and the rest of Microsoft's .NET vision, visit http://www.microsoft.com/net.
The CLR as a development platform
The CLR is a development platform. Like any platform, it provides a runtime, defines functionality in some libraries, and supports a set of programming languages.
The CLR is a platform for developing applications. A platform is a set of programmatic services, exposed through some API to developers using one or more languages. Development generally targets a single platform; when I write a program using Visual Basic, I say that I'm writing it for Windows, my target platform. The forms and controls that I develop won't run directly on, say, Apple's Mac OS X.
The CLR is not an operating system in the strict sense of the term - it does not, for example, provide a file system, relying instead on the underlying OS (such as Windows) to implement that feature. The CLR is, however, a platform, and in much the same way that code written for Unix will not run on Windows, code must specifically target the CLR. Don't panic, though, because there's plenty of consideration given to interoperating with existing, non-CLR code. You'll still be able to use your existing COM objects and DLLs while taking advantage of the new features of CLR development.
The Common Language Runtime is Microsoft's development platform of the future. In Microsoft's vision of the world, most future software will be written to make use of the CLR features. We'll be looking at what the CLR provides you so you can decide for yourself whether the advantages outweigh the costs. Now, assuming that you agree that this new platform offers significant advantages over your current platform, you might wonder, "What's the big picture? What things do I need to learn in order to develop for the CLR?"
When I approach any new platform, be it a new operating system, the CLR, or even an application suite that allows automation of its features, like Microsoft Office or SAS, I mentally break down the feature set of the platform into three fundamental areas: the runtime that the platform offers, the libraries it defines, and the languages I'm going to use. These aspects of the platform overlap (see figure 2), and understanding each of them and the ways in which they interact is crucial to becoming an effective CLR programmer.
Jit
JIT
Machines cannot run IL directly. A process known as JIT compilation turns IL into executable code.
We could consider IL to be the machine language of the CLR. Whatever we call it, it's metadata that describes implementation. But because it's not x86 assembly instructions, like we stored in COM and vanilla DLLs, it cannot be executed directly by a computer. We rely on yet another service of the platform to make this magic happen: Just-In-Time Compilation.
Just-In-Time compilation (JIT for short) is the process by which the runtime examines the IL in our assemblies and creates code that can be executed by whatever processor we happen to be running on. The "Just-In-Time" comes from the fact that the runtime performs this compilation at runtime, every time the component is loaded into a new process[22] [23]. This is true compilation - the IL is turned into actual machine code a method at a time. Interpretation - reading one IL instruction at a time and executing it - never occurs in code targeting the CLR.
This is an important point. Because the code is being compiled - converted to machine code en masse - rather than reading and then executing one IL instruction after another - performance of code in the CLR should be quite good.
In fact, JIT code could even outperform unmanaged code in some situations, because it knows things that a normal compiler doesn't, like exactly what processor (
Some of you may remember what a pain it was to move 16-bit Windows 3.1 code to the 32-bit Windows NT or Windows 95 platform. A similar ordeal faces us in the coming years as new 64-bit processors become available. Anyone coding the old way, where your development tools create components that contain actual machine instructions, will need to rewrite everything to take advantage of the new machines. However, anyone that is making use of JIT compilation technology can rely on the runtime to emit the correct code - your components don't have to change at all. The only thing we need to update is the JIT compiler itself, rather than hundreds or thousands of individual components. This is one of the biggest advantages to adding this level of indirection between what our compilers produce and what eventually gets executed by the target computer.
While JIT compilation theoretically[25] gives us the ability to write code that can run on a variety of platforms, there are other great benefits to this approach as well. One of these is something known as code verification. Because we have metadata about the implementation - CIL - and a runtime that understands it, we can get something we never had in COM: an assurance that the code doesn't do anything it shouldn't be allowed to.
Assemblies
An assembly is a collection of types and resources that forms a logical unit of functionality. All types in the .NET Framework must exist in assemblies; the common language runtime does not support types outside of assemblies. Each time you create a Microsoft Windows® Application, Windows Service, Class Library, or other application with Visual Basic .NET, you're building a single assembly. Each assembly is stored as an .exe or .dll file.
Note Although it's technically possible to create assemblies that span multiple files, you're not likely to use this technology in most situations.
The .NET Framework uses assemblies as the fundamental unit for several purposes:
· Security
· Type Identity
· Reference Scope
· Versioning
· Deployment
Security
An assembly is the unit at which security permissions are requested and granted. Assemblies are also the level at which you establish identity and trust. The .NET Framework provides two mechanisms for this level of assembly security: strong names and SignCode.msi. You can also manage security by specifying the level of trust for code from a particular site or zone.
Signing an assembly with a strong name adds public key encryption to the assembly. This ensures name uniqueness and prevents substituting another assembly with the same name for the assembly that you provided.
The signCode.msi tool embeds a digital certificate in the assembly. This allows users of the assembly to verify the identity of the assembly's developer by using a public or private trust hierarchy.
You can choose to use either strong names, SignCode.msi, or both, to strengthen the identity of your assembly.
The common language runtime also uses internal hashing information, in conjunction with strong names and signcode, to verify that the assembly being loaded has not been altered after it was built.
Type Identity
The identity of a type depends on the assembly where that type is defined. That is, if you define a type named DataStore in one assembly, and a type named DataStore in another assembly, the .NET Framework can tell them apart because they are in two different assemblies. Of course you can't define two different types with the same name in the same assembly.
Reference Scope
The assembly is also the location of reference information in general. Each assembly contains information on references in two directions:
· The assembly contains metadata that specifies the types and resources within the assembly that are exposed to code outside of the assembly. For example, a particular assembly could expose a public type named Customer with a public property named AccountBalance.
· The assembly contains metadata specifying the other assemblies on which it depends. For example, a particular assembly might specify that it depends on the System.Windows.Forms.dll assembly.
Versioning
Each assembly has a 128-bit version number that is presented as a set of four decimal pieces: Major.Minor.Build.Revision
For example, an assembly might have the version number 3.5.0.126.
By default, an assembly will only use types from the exact same assembly (name and version number) that it was built and tested with. That is, if you have an assembly that uses a type from version 1.0.0.2 of another assembly, it will (by default) not use the same type from version 1.0.0.4 of the other assembly. This use of both name and version to identify referenced assemblies helps avoid the "DLL Hell" problem of upgrades to one application breaking other applications.
Tip An administrator or developer can use configuration files to relax this strict version checking. Look for information on publisher policy in the .NET Framework Developer's Guide.
Deployment
Assemblies are the natural unit of deployment. The Windows Installer Service 2.0 can install individual assemblies as part of a larger setup program. You can also deploy assemblies in other ways, including by a simple xcopy to the target system or via code download from a web site. When you start an application, it loads other assemblies as a unit as types and resources from those assemblies are needed.
The Assembly Manifest
Every assembly contains an assembly manifest, a set of metadata with information about the assembly. The assembly manifest contains these items:
· The assembly name and version
· The culture or language the assembly supports (not required in all assemblies)
· The public key for any strong name assigned to the assembly (not required in all assemblies)
· A list of files in the assembly with hash information
· Information on exported types
· Information on referenced assemblies
In addition, you can add other information to the manifest by using assembly attributes. Assembly attributes are declared inside of a file in an assembly, and are text strings that describe the assembly. For example, you can set a friendly name for an assembly with the AssemblyTitle attribute:
Table 1. Standard assembly attributes
| Attribute | Meaning |
| AssemblyCompany | Company shipping the assembly |
| AssemblyCopyright | Copyright information |
| AssemblyCulture | Enumeration indicating the target culture for the assembly |
| AssemblyDelaySign | True to indicate that delayed signing is being used |
| AssemblyDescription | Short description of the assembly |
| AssemblyFileVersion | String specifying the Win32 file version. Defaults to the AssemblyVersion value. |
| AssemblyInformationalVersion | Human-readable version; not used by the common language runtime |
| AssemblyKeyFile | Name of the file containing keys for signing the assembly |
| AssemblyKeyName | Key container containing a key pair to use for signing |
| AssemblyProduct | Product Name |
| AssemblyTitle | Friendly name for the assembly |
| AssemblyTrademark | Trademark information |
| AssemblyVersion | Version number expressed as a string. |
You can also define your own custom attributes by inheriting from the System.Attribute class. These attributes will be available in the assembly manifest just like the attributes listed above.
The Global Assembly Cache
Assemblies can be either private or shared. By default, assemblies are private, and types contained within those assemblies are only available to applications in the same directory as the assembly. But every computer with the .NET Framework installed also has a global assembly cache (GAC) containing assemblies that are designed to be shared by multiple applications. There are three ways to add an assembly to the GAC:
· Install them with the Windows Installer 2.0
· Use the Gacutil.exe tool
· Drag and drop the assemblies to the cache with Windows Explorer
Note that in most cases you should plan to install assemblies to the GAC on end-user computers by using the Windows Installer. The gacutil.exe tool and the drag and drop method exist for use during the development cycle. You can view the contents of your global
0 comments;Click here for request info on this topic:
Post a Comment