Introduction :-

Microsoft's long-term decision to replace COM with the CLR, you should strive to understand the underlying advantages of migrating from the old runtime environment to the new one. The architects that designed the CLR and the .NET platform were able to incorporate the best aspects of COM while alleviating much of the pain of writing and deploying COM-based applications.

CLR-ELIMINATION OF COM'S PROBLEMS

The COM's most frustrating problems are

1.Language interoperability.
2.Application deployment.
3.Component versioning.

The new programming model introduced by the CLR serves to eliminate many of COM's unnecessarily confusing details with regard to writing and understanding the code for a distributed application
The history of COM has been plagued with problems concerning interoperability of various languages. While a certain degree of interoperability exists between unmanaged languages, it is far from ideal. For example, it's common for C++ programmers to produce component DLLs that are unusable from Visual Basic or scripting languages. Many built-in C++ types for dealing with things such as strings, arrays, and pointers are either impossible or impractical to consume from other languages.

The CLR ensures higher levels of interoperability. The programming model of the CLR is based on the universal type system. Every managed language must be layered on top of and mapped to this core set of built-in types

The CLR type system defines a predictable set of primitive types containing things like integers and floating point numbers. The CLR's type system also defines standard classes for other types, such as String, Array, and Exception.Languages such as Visual Basic .NET and C# provide keywords that map directly to many of the built-in CLR types. For example, Visual Basic .NET provides the Integer keyword, which is the equivalent of the int keyword in C#. Both types map directly to the CLR's System.Int32 type.

The CLR improves upon COM by standardizing on a universal set of types that are shared across all managed languages. For example, the CLR's type system provides various built-in types for unsigned integers. Unsigned integers are fully supported by C#, but not by Visual Basic .NET. This means there's a potential for a C# programmer to create a component that exposes unsigned integers in a manner that would make it either awkward or impossible to access from other languages

In order to prevent situations in which programmers mistakenly create components that are inaccessible from other managed languages, Microsoft has created a document called the Common Language Specification (CLS). The CLS defines a subset of CLR types and features that component and consumer languages must support to effectively interoperate with other managed languages.

Visual Basic .NET is fully compliant with the CLS. In addition, the class libraries built into the CLR are fully accessible from any CLS-compliant language, including Visual Basic .NET. This is a great news for programmers using Visual Basic who, in the past, have had to accept that many parts of their underlying platform (such as the Win32 API and OLE32.DLL) are inaccessible from their chosen language. Full access to the CLR class libraries really levels the playing field with respect to what can be done with Visual Basic when compared to other managed languages.

The type system of the CLR relies heavily on inheritance. The entire type system is based on a single-inheritance hierarchy. All managed types used to create objects ultimately derive from the single root type System.Object. When you create a class without explicitly inheriting from another class, your class implicitly inherits from System.Object. That means that a class declaration like this:

Public Class Class1 '
class member declarations go here
End Class

is equivalent to this class declaration:

Public Class Class1
Inherits System.Object class member declarations go here
End Class

If you want to derive one user-defined class from another, the syntax looks like this:

Public Class Class2
Inherits Class1 ' class member
declarations go here
End Class

Note that Visual Basic .NET requires you to separate the name of the deriving class and the Inherits keyword using a line break. If you'd like to write Visual Basic .NET code to purposely confuse all those know-it-all C++ programmers out there, you can substitute a colon for the line break like this:

Public Class Class2 :
Inherits Class1 ' class member declarations go here
End Class

This syntax more closely resembles C# and C++, where the colon is required when using inheritance. However, with Visual Basic .NET, it's important to realize that the colon is just acting as a line break.

A key point to observe is that any managed type from which you can create an instance ultimately inherits from System.Object. This also includes primitive types such as integers, longs, and doubles. This means that all variables can be cast to the System.Object type regardless of whether they are reference types or value types. You should also keep in mind that the Visual Basic .NET language has moved the functionality of older unmanaged types such as the variant, IUnknown and IDispatch into System.Object.

A Richer Format for Component Metadata:

The .NET Framework uses the term "module" to refer to a managed binary such as a DLL or an EXE. Every managed language must have a compiler that is capable of building an extensive set of component metadata into each module to describe the types it contains. A module holds component metadata and the MSIL code for the managed types it contains. The component metadata in a module is similar to the type information stored in the type library of a COM DLL because it exposes information to client applications about its public types (such as enumerations, structures, interfaces, and classes). However, there are a few important differences that make the type information for managed components much richer than the type information used by COM. First, all component metadata must adhere to a single, high-fidelity format for describing managed type information. This eliminates problems experienced by COM developers with fidelity loss between the type information format used in type libraries and the format used in Interface Definition Language (IDL). What's more, .NET development is easier than COM development because you never need a separate language like IDL to define your types. Custom types can always be fully described using a managed language such as Visual Basic .NET or C#.

Another big difference between COM and the CLR is that managed components contain far more metadata for describing classes. In COM, a class's type information is defined in a type library in terms of a coclass. The COM coclass type is limited in the sense that it only describes a class in terms of which interfaces it supports. COM has very strict rules about separating interface from implementation, and the limited information in a coclasses definition is very much in line with that philosophy. While COM requires a formal separation of interface from implementation, Visual Basic has always made things easier by automatically building a default interface behind every multiuse class. When a Visual Basic client contains a reference variable based on a class name, the Visual Basic compiler silently casts the reference to the default interface for the class. Visual Basic, therefore, has been able to hide the fact that COM requires a formal separation of interface from implementation types. The architects of the CLR have taken a view of classes that is much more in line with Visual Basic than with COM. The component metadata for a managed class can expose its public methods as part of a default interface. This offers much more flexibility.

Unlike COM, you don't need to define a standalone interface in order to program against a class. The key point is that you don't have to work in terms of interfaces in situations when a class with public methods is an acceptable and much easier alternative. While the CLR architects have removed the requirement to work in terms of standalone interfaces, you should by no means interpret this to mean that interface-based programming isn't important when writing managed code. Programming in terms of explicit interfaces is as important as ever when you want to create plug-compatible classes or decouple one subsystem from another in a large scale application. Furthermore, the CLR class libraries frequently expose their functionality through interfaces. Any intermediate or advanced programmer should be very comfortable defining, implementing, and using interface types.

While both COM and the CLR require components to expose public type information, the CLR is different from COM in that it requires modules to expose internal type information to the system. This internal type information is used by the CLR at runtime to create and manage objects. This allows the CLR to perform many tasks which the COM runtime delegates to component DLLs and client applications. A COM type library doesn't contain any type information to describe how objects should be represented in memory. Instead, it's the responsibility of a COM DLL to allocate and release the memory for its objects. A COM DLL also has the responsibility of laying out its objects with COM-compliant vtables. In the CLR, these responsibilities have been removed from component DLLs and transferred to the underlying runtime environment. The CLR takes on the responsibility of allocating and releasing the memory for objects. When a client makes a request to create an object from a managed class, the CLR discovers the object's memory and layout requirements by examining internal type information about the class at runtime. This allows the CLR to allocate the proper amount of memory during object creation. The CLR also uses internal type information to create the binding that allows clients to execute methods on objects. This means that managed binaries, unlike COM binaries, don't have to contain code to generate or access COM-style vtables. The CLR takes on more responsibilities than the COM runtime. This has allowed the CLR architects to remove much of the complexity and extra baggage that is built into COM binaries, such as class factories and code for dealing with vtables.

Garbage Collection for Managing Object Lifetimes:

The important architectural difference between COM and the CLR. COM uses reference counting to manage object lifetimes. When you release the last reference to a COM object, it synchronously removes itself from memory. If your class contains some custom cleanup code in an implementation of Class_Terminate, you get the guarantee that this code will run in a deterministic fashion. This is not the case when running managed objects in the CLR. The CLR manages object lifetime through garbage collection. This is very different from the reference counting that COM uses to manage object lifetimes. The CLR always creates objects on a garbage-collected heap. When a client releases the last reference to an object, the object is not instantly removed from memory. Instead, the garbage collector removes the object from memory at some indeterminate time in the future.

Advantage of Garbage collection:

The two primary reasons you would prefer garbage collection over reference counting are enhanced performance and the ability of the system to detect and break down circular references between objects. The designers of the CLR decided that these reasons were sufficient grounds for using garbage collection for lifetime management rather than using the model used by COM.

CONCLUSION:

The new programming model introduced by the CLR serves to eliminate many of COM's most frustrating problems such as Language interoperability,Application deployment,Component versioning. The CLR provides much more flexibility and adaptability when it comes to finding loadable modules and resolving types at runtime.