Compared to COM, .NET might seem to be missing many things you take for granted as part of developing components. However, in essence, the missing elements are actually present in .NET, although in a different fashion:

.NET has a superb development environment and semantics, the product of years of observing how developers use COM and the hurdles they faced.

.NET does not rely on the Registry for anything that has to do with your components. In fact, installing a .NET component is as simple as copying it to the directory of the application using it. .NET maintains tight version control, enabling side-by-side execution of new and old versions of the same component on the same machine. The net result is zero-impact install—by default, you cannot harm another application by installing yours, thus ending the predicament known as DLL Hell. The .NET motto is: it just works. If you want to install components to be shared by multiple applications, you can install them in the Global Assembly Cache (GAC). If the GAC already contains a previous version of your assembly, it keeps it for use by clients that were built against the old version. You can purge old versions as well, but that is not the default.

.NET does not use reference counting to manage an object’s life cycle. Instead, .NET keeps track of accessible paths in your code to the object. As long as any client has a reference to an object, it is considered reachable. Reachable objects are kept alive. Unreachable objects are considered garbage, and therefore destroying them harms no one. One of the crucial CLR entities is the garbage collector . The garbage collector periodically traverses the list of existing objects. Using a sophisticated pointing schema, it detects unreachable objects and releases the memory allocated to these objects. Consequently, clients do not have to increment or decrement a reference count on the objects they create.

In COM, the object knows that it is no longer required by its clients when its reference count goes down to zero. The object then performs cleanup and destroys itself by calling delete this;. The ATL framework even calls a method on your object called FinalRelease( ), letting you handle the object cleanup.

In .NET, unlike COM, the object itself is never told when it is deemed as garbage. If the object has specific cleanup to do, it should implement a method called Finalize( ). The garbage collector calls Finalize( ) just before destroying the object. Finalize( ) is your .NET component’s destructor. In fact, even if you implement a destructor (such as the one in Example C-1), the compiler will convert it to a Finalize() method.

public class MyClass
{
    public MyClass(  ){}    
    ~MyClass(  ){}
}

public class MyClass
{
    public MyClass(  ){}    
    protected virtual void Finalize(  )
    {
	   try
       {
          //Your destructor code goes here
       }
       finally
       {
          base.Finalize(  );//everybody has one, from Object 
       }
    }
}

However, simplifying the object lifecycle comes with a cost in system scalability and throughput. If the object holds on to expensive resources, such as files or database connections, those resources are released only when Finalize( ) is called. It is called at an undetermined point in the future, usually when the process hosting your component is out of memory. In theory, releasing the expensive resources the object holds may never happen, and thus severely hamper system scalability and throughput.

There are two solutions to the problems arising from nondeterministic finalization. The first solution is to implement methods on your object that allow the client to explicitly order cleanup of expensive resources the object holds. If the object holds onto resources that can be reallocated, then the object should expose methods such as Open( ) and Close( ).

An object encapsulating a file is a good example. The client calls Close( ) on the object, allowing the object to release the file. If the client wants to access the file again, it calls Open( ) without re-creating the object. The more common case is when disposing of the resources amounts to destroying the object. In that case, the object should implement a method called Dispose( ). When a client calls Dispose( ), the object should dispose of all its expensive recourses, and the client should not try to access the object again. The problem with both Close( ) and Dispose( ) is that they make sharing the object between clients much more complicated than COM’s reference counts. The clients have to coordinate which one of them is responsible for calling Close( ) or Dispose( ) and when Dispose( ) should be called; thus, the clients are coupled to one another.

The second solution to nondeterministic finalization is to use COM+ JITA, as explained in Chapter 10.

COM and .NET are fully interoperable. Any COM client can call your managed objects, and any COM object is accessible to a managed client. To export your .NET components to COM, use the TlbExp.exe utility, also available as a command from the Tools menu. The utility generates a type library that COM clients use to CoCreate managed types and interfaces. You can use various attributes on your managed class to direct the export process, such as providing a CLSID and IID.

To import an existing COM object to .NET (by far the most common scenario), use the TlbImp.exe utility. The utility generates a managed wrapper class, which your managed client uses. The wrapper manages the reference count on the actual COM object. When the wrapper class is garbage collected, the wrapper releases the COM object it wraps. You can also import a COM object from within the Visual Studio.NET environment by selecting the COM object from the project reference dialog (which makes Visual Studio.NET call TlbImp for you).

.NET has support for invoking native Win32 API calls, or any DLL exported functions, by importing the method signatures to the managed environment.