Microsoft announced the .NET framework in July 2000, it’s biggest initiative since the launch of Windows in 1991. .NET (pronounced dotnet) is a revolutionary multi-language platform that knits various aspects of application development together with the Internet. The framework covers all layers of software development above the Operating system. Several software will be developed by Microsoft to achieve this goal. It is expected that every player in the industry, be it a software developer or a device manufacturer, adopt .NET so that they can be integrated. The .NET initiative is all about enabling data transfer between networks, PCs and devices seamlessly, independent of the platforms, architecture and solutions. Microsoft has taken many of the best ideas in the industry, combined in some great ideas of their own, and brought them all in to one coherent package. One of the other biggest problems faced by programmers is that, a program developed in one software cannot run on the other. An application developed in a particular Software needs its respective runtime files. A runtime is a component that a computer must have in order to execute programs written in a particular programming language. With the .Net’s introduction of a single Common Language Runtime (CLR), which compiles source codes of all . NET programs to machine code, the developers can share their applications and components without having the problem of changing the specific runtime files. All .NET languages such as C#, VB. NET, Jscript. NET etc share this runtime. .NET Framework provides a run-time environment called the Common Language Runtime (CLR) that all .NET languages share. The CLR manages the execution of code and provides services that make the development process easier. Compilers and tools expose the runtime's functionality and enable you to write code that benefits from this managed execution environment. The runtime uses Metadata to locate and load classes, Lay out instances in memory, Resolve method invocations, Generate native code, Enforce security, Set up run time context boundaries. The source code is compiled to MSIL (Microsoft Intermediate Language) and at the same time metadata information is created using the metadata engine. These are linked with other code compiled by different compilers and the result is an EXE or DLL containing the MSIL code, which is saved to disk. The compiler’s work is now done. Then on execution, the IL code and any functionality from the . NET base class library is brought together using the
class loader. The combined code is optionally tested for type safety using the verifier before JIT compiler comes into play. The JIT( Just in Time) compiler processes the MSIL creating managed native code, which is passed on to the .NET runtime manager. A dynamic link library (DLL) is a collection of small programs, any of which can be called when needed by a larger program that is running in the computer. The small program that lets the larger program communicate with a specific device such as a printer or scanner is often packaged as a DLL program, usually referred to as a DLL file. DLL files that support specific device operation are known as device driver. The advantage of DLL files is that, they don't get loaded into random access memory together with the main program, space is saved in RAM. When and if a DLL file is needed, then it is loaded and run. For example, as long as a user of Microsoft Word is editing a document, the printer DLL file does not need to be loaded into RAM. If the user decides to print the document, then the Word application causes the printer DLL file to be loaded and run. A DLL file is often given a ".dll" file name suffix. DLL files are dynamically linked with the program that uses them during program execution rather than being compiled with the main program. The set of such files (or the DLL) is comparable to the library routines provided with programming languages such as C and C++. The Garbage Collector (GC) is responsible for removing objects from the Managed heap that are no longer referenced, compacting the remaining allocations, and then finally resetting the reference to the end of the memory allocations on the heap. The GC may be automatically invoked by the CLR. The GC helps resolve many of the memory leak problems we are plagued with today. Code that U develop with a language compiler that targets the runtime is called managed code. It benefits from features such as Cross-language integration, Cross-language exception handling, Enhanced security, Versioning and deployment support, The runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. Objects whose lifetimes are managed in this way by the runtime are called managed data. Automatic memory management eliminates memory leaks as well as some
other common programming errors. If your code is managed, you can use managed data. A managed heap is a region of memory that is allocated and managed by the CLR. An assembly is a collection of files that work together, and must all reside in the same directory on the disk. An assembly can contain more than just code, you can add any resource files, such as bitmaps, which are needed for your code to function, into the assembly. An assembly is not an application. An
application is built from one or more assemblies.
A Manifest contains vital information of the assembly. Every assembly should have a Manifest. It may be a separate file in the assembly or it may be contained in one of the modules. It contains: 1. Name and Version number of the assembly. 2. Other assemblies that this assembly depends upon. 3. Types exposed by the assembly, 4. Security permissions required by the assembly. A module is either a DLL or an EXE in the Windows PE (Portable Executable ) format. A module also contains it’s own necessary metadata, and one module in an assembly a manifest for that assembly. Microsoft intermediate language (MSIL) is a CPU-independent set of instructions that can be efficiently converted to native code. If you compile your source code to managed code, the compiler translates your source code into MSIL. MSIL includes a wide spectrum of instructions, such as Instructions for loading, storing, initializing Calling methods on objects Instructions for arithmetic and logical operations, Control flow, direct memory access, and exception handling. When a compiler produces MSIL, it also produces metadata. The metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and extends the published PE and Common Object File Format (COFF) used for executable content. This file format, which accommodates MSIL or native code as well as metadata, enables the operating system to recognize Common Language Runtime images. The presence of metadata in the file along with the MSIL enables your code to describe itself, which means that there is no need for type libraries or IDL. The runtime locates and extracts the metadata from the file as necessary during execution.
All .NET programs are compiled to an Intermediate language (IL) rather than to native code, which can be understood by the computer processor. This IL code is then compiled to native code either when the application is installed, or when the application is run. This way of two-time compilation provides interoperability of all .NET languages and may extend platform independence in the future. Before code can be executed, MSIL must be converted to CPU-specific code by a just in time (JIT) compiler. Because the runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and executed on any supported architecture. Because the runtime supplies a JIT compiler for each CPU architecture that the runtime operates on, developers can write a set of MSIL that can be JIT-compiled and executed on computers with different architectures. Standard JIT is the default JITter. Standard JIT or just JIT produces highly optimized machine code. When an IL function or method is invoked, JIT analyzes, compiles, and caches it very fast. All . NET programs using JIT become faster and faster as the various branches of execution within them are converted to pure native code. EconoJIT, the second JITter targets small hardware platforms that do not have a lot of RAM. EconoJIT produces machine code that is efficient but not optimal. Because EconoJIT performs fewer optimizations than JIT does, it compiles faster. PreJIT is not really a JITter in its own right. Rather, it is the invocation of the Standard JIT at the time when an application is installed on a system. With PreJIT, the entire application is completely converted from IL to machine code.
In the past, a compiled component (.exe or .dll) was only able to communicate with another compiled component through a binary interface. Furthermore, since different languages sometimes had conflicting protocols, inter-language communication was made difficult. The .NET Framework solves these problems by allowing compilers to emit additional declarative information into all .NET Framework files and assemblies. This information called metadata, serves as a roadmap for compiled files to seamlessly interact.
Metadata is binary information describing your code stored in a .NET Framework portable executable (PE) file or in memory. Every type and member defined and referenced in a file or assembly is described within
metadata. Metadata provides a common frame of reference that enables
communication between the runtime, compilers, debuggers, and code that has been compiled into MSIL. It also helps the runtime and garbage
collection keep track of memory that will be released back to the operating system when it is no longer needed. The information stored in metadata also enables the Common Language Runtime to enforce security. Metadata provides so much information about compiled code that you can actually inherit a class from a PE file written in a different language. Everything one component needs in order to interact with another component is provided within that component's metadata. Since the compiler is responsible for creating metadata, you do not directly control much of what is emitted. However, the Common language Runtime allows you to declare specific kinds of metadata, called attributes, in your compiled file. Additionally, you can emit your own custom metadata into .NET Framework files by user-defined custom attributes. The Common Language Runtime provides the infrastructure that enables execution to take place as well as a variety of services that can be used during execution. Before a method can be executed, it must be compiled to processor-specific code. Each method for which MSIL has been generated is JIT-compiled when it is called for the first time, then executed. The next time the method is executed, the existing JIT-compiled native code is executed. The process of JIT compiling and then executing the code is repeated until execution is complete. The first step in the managed execution process is designing the source code. If you want your application to have the benefits provided by the Common Language Runtime, you must use one (or more) language compilers that target the runtime, such as Visual Basic, C#, Visual C++, or one of many third party compilers such as a Perl or COBOL compiler.To determine whether a .exe or .dll is managed, run the ILDASM utility over the file, by typing “ILDASM MyFile.exe”. If the file is not managed, ILDASM will display the message, "MyFile.Exe has no valid CLR header and cannot be disassembled." Otherwise, ILDASM will run successfully. The common type system describes the types supported by the runtime and specifies how those types can interact with each other and how they are persisted in metadata.The Microsoft .NET Framework is built on the type system that the runtime defines. It supplies built in primitive types as well as other types. 1. The type system is an important part of the runtime's support for crosslanguage integration because it provides the rules that language compilers follow with respect to defining, referencing, using, and storing types.
2. The fact that types are created and used consistently by language compilers supplies the basis for ensuring that objects written in different
languages can interact with each other.
The .NET Framework includes classes, interfaces, and value types that help expedite and optimize the development process and give you access to system functionality. It also includes types that encapsulate data structures, perform I/O, give you access to information about a loaded class, and provide a way to invoke .NET Framework security checks, as well as classes that encapsulate exceptions, and other helpful functionality such as data access, server controls and rich GUI generation. .NET Framework types are named using a dot-syntax naming system that connotes a naming hierarchy. The use of naming patterns to group related classes into namespaces is a very useful way to build and document class libraries. A namespace may be partitioned across multiple assemblies and a single assembly may contain classes from multiple namespaces. To the runtime, a namespace is just a collection of type names. Particular languages have constructs and corresponding syntax that help developers form logical groups of classes, but these constructs are not used by the runtime when binding types. For example, you can build a single assembly that exposed types that look like they come from two different hierarchical namespaces, such as System.Collections and System.WinForms. You can also build two assemblies that both export types whose names contain "MyDll.MyClass."
The root namespace for the types in the .NET Framework is the System namespace. This namespace includes classes that represent the base data
types used by all applications. Many of these types correspond to the primitive data types that your language compiler uses. Along with the base data types, there are almost 100 classes directly in the System namespace ranging from classes for handling exceptions and forming delegates to dealing with core runtime concepts such as application domains and the automatic memory manager. The System namespace also contains 24 secondlevel namespaces.
.NET Framework objects automatically have the ability to communicate and interact with each other, even if they are written in different languages. Your
objects can call methods on other objects, inherit implementation from other objects, and pass instances of a class to another class's methods, regardless of the language they are implemented in. In addition, the runtime’s language interoperability enables any debugger to understand your multi-language application and step through it.
Exception handling reveals another aspect of language interoperability: the runtime enables exceptions to be handled the same way across languages. Your code can throw an exception in one language and that exception can be caught and understood by an object written in another language. In some scenarios, language interoperability is particularly desirable. Suppose you have developed several components for your server application in one language, and you realize later that another language is better suited for implementing the functionality that the remaining component provides. For objects to be able to understand each other no matter what language compiler they are compiled with, they must expose to callers only those data types and features that are common to all the languages they need to interoperate with. For this reason, the runtime has identified a set of language features called the Common Language Specification (CLS), which includes the basic language features needed by many applications. If your component uses only CLS features in the API that it exposes to other code, including subclasses, the component is guaranteed to be accessible from any object compiled by a language compiler that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components. When you design CLS-compliant components, it is helpful to use a language compiler that has the ability to produce CLS-compliant components. In some cases, these language compilers will assist you by providing a "switch" that you can throw to tell the compiler that you want your code to be CLScompliant. The compiler will let you know when your code uses functionality that is not supported by the CLS. If you design a CLS-compliant framework (class library), your library will be usable from many programming languages, including code written using CLS-compliant consumer tools and code written using CLS-compliant extender tools. If you want your component or application to be CLS-compliant, you must use only CLS features 1) In the definitions of your public classes 2) public members of public classes 3) the definitions of members accessible to subclasses, 4) In the parameters of public methods of public classes, 5) In the parameters of methods accessible to subclasses. Many language compilers targeting the runtime have agreed to support the data types and features in the CLS. These language compilers simplify CLS-
compliance by making the CLS data types and features available to you so that you can create components using them. The levels of CLS-compliance among compilers and other tools are described here. Language compilers that allow developers to both use and extend types are defined in CLS-compliant libraries. Developers can use existing types as well as define new types. Configure an application around the fact that you can change what assemblies are used, the level of security that is required, as well as other factors, by developing configuration files to accompany the application. Because the Common Language Runtime assemblies are self-describing and define the relationships of their components, application installation and deployment is greatly simplified. Runtime applications do not require any registry entries; deploying a runtime application can be as simple as copying the assemblies that constitute an application to a directory structure on disk. The runtime can then launch the application and resolve all references directly from the file system. Because each assembly describes where to locate the classes it contains, there is no need to make registry entries of any kind. To deploy runtime files, you can create either .msi files for use with the Windows Installer or .cab files for distribution by downloading or copying. If you intend to deploy files from a website, assemblies are downloaded automatically into the download cache when they are referenced. The Common Language Runtime configuration system allows administrators and developers to configure those aspects of an application that are either specific to the deployment environment, or can logically be changed after the application was built. By default, all information that the runtime needs to locate, load, and execute an application is available either implicitly or within the manifest for each assembly that is loaded as a part of that application. A typical example of configuration data is security policy. When building an assembly, a developer specifies the set of permissions that are required for the code to run. However, the decision of whether to grant the assembly the requested permissions is up to the administrator who creates a configuration file, and is made independent of when the assembly was built. An administrator will be able to configure a) Security policy, at both the machine and user level; b) Application behavior c) Runtime behavior. The .NET Framework provides two mechanisms for protecting resources and code from unauthorized code and users:
Code access security uses permissions to control the access to protected
resources and operations. It helps protect computer systems from malicious mobile code and also provides a way to allow mobile code to run safely. Role-based security provides information needed to make decisions about what a user is allowed to do. These decisions can be based on either the user's identity or role membership or both. Security policy is the configurable set of rules that the runtime follows when deciding which permissions to grant to code. The runtime determines the access to resources code by examining identifiable characteristics of the code, such as the web site or zone from which the code originated. One of the major goals of .NET is to simplify installation and care for computing infrastructure and to reduce the burden of the people who do it. By alleviating the problems created by DLL files and many other deployment problems, infrastructure workers will be relieved of many of the most frustrating and tedious aspects of Microsoft platform deployment. On the other hand, with applications becoming more distributed through web services, the need for reliable connection both within organization and through out the Internet will increase. This will put more responsibilities on the infrastructure technician. A Component is a compiled library of classes that can be referenced and used by other programs. . NET provides developers with a new way of building and using components. The . NET components also known as Assemblies do not have to be entered into the system registry. The . NET assembly files encapsulate their own information in special sections known as manifests. An assembly is a collection of files that work together, and must all reside in the same directory on the disk. It can contain more than just code, you can add any resource files, such as bitmaps, which are needed for your code to function, into the assembly. An assembly is not an application. An application is built from one or more assemblies. There are currently two problems with Win32 architecture that have combined to give us what is known as DLL Hell. In DLL Hell, there is no control entity that is responsible for the management of all the DLL files installed onto a system. Since the information about a COM DLL is only held in the registry, it can easily be over written by another application. Further an application can partially install over another, overwriting its DLL’s. This can play havoc with any existing application that was relying on that particular DLL performing a specific function when a method is called. One of the major problems with Win32 is that there is no system-level enforcement of versioning rules between components. The other problem is that there is no way for an application to say that it needs version 1.2.1.1234 of a particular component. If the version that it finds is different, even if the
interface is still intact, the code that it is relying on may no longer be there, or may not perform in the way expected. To try to combat this, Windows 2000 added System File Protection. This is an OS feature that can stop an installation program from overwriting system DLLs. The Common Language Runtime (CLR) extends this support by allowing developers to specify the specific version of a component that they want their application to use. It provides a means to make sure that the proper version is located and used by the requesting application. It also allows for the execution of code from two similar components that only differ in version. This is known as side-by-side execution. In order for an assembly to describe itself to the CLR it must contain a set of metadata. This metadata is contained in the assembly’s manifest and specifies the assembly version, the security information for the assembly, the scope of the assembly and the information to resolve references to the resources and classes of the assembly. The manifest of an assembly can be stored in an EXE, a DLL, or a stand-alone file. The manifest will specifically contain the above given pieces of metadata. This is a textual string name that identifies the assembly. When an assembly is shared, a unique naming method must be used. This is called a shared name, and creating one allows the assembly to be stored in the global assembly cache that is used to store assemblies that can be used by several applications on the machine.
The CLR has the ability to create small, temporary objects very quickly and economically. In fact, the runtime can allocate nearly 10
million objects per second on a moderately fast machine. Also an object running in the CLR will be Garbage Collected once it is no longer being referenced. This will happen automatically, and keeps the developer from having to deal with memory leaks from improperly freed objects. Attributes in the CLR allow developers to add additional information to the classes. These are then available to the application using the component through the System.Reflection classes. Attributes can be used as compiler flags to tell the compiler how to handle the compilation of a class. They can also be used to identify the transaction characteristics of a class. There are a set of standard attributes for properties and events that are defined in the System.ComponentModel class in the CLR. Earlier, it was quite difficult to have components written in one language subclass and extend a component written in another. However now, with the CLR and the .NET Framework, we have the ability to do this. Cross-language inheritance also makes debugging much easier. The other key advantage to cross-language inheritance is that it makes a great way to create class
libraries. The cross-language inheritance capabilities of the CLR allow for any supported language to both use the Framework as well as create new classes that inherit from classes within the Framework.
Any code that runs outside of the Common Language Runtime (CLR) is known as unmanaged code. This includes all COM (Component Object Model) components, Active X controls, and any calls to the native Win32 API- all are considered to be unmanaged code. In order to use a COM component there are many things that we need to look at in the implementation and deployment of the component. The COM components have no concept of metadata associated with them. There is a separate type library file that functions like assembly metadata, but it is part of a separate file and not related in any way to the component itself To build the metadata for a COM component so that it can be used within the .NET framework a tool called the “Type Library Importer’’ is used. This tool is included with the .NET Framework SDK and will create an assembly containing the necessary metadata for the COM component. It uses the component’s type library to create the metadata.