.NET Components Versus Registered COM Components

So what is so different about .NET components and COM components? Does DLL Hell ring any bells? This problem is eliminated with .NET components. You no longer have to register your DLL on the server to use it; you just need to copy it to your in directory to be executed.

COM components need to be registered in the registry, whereas .NET components only need to be placed in the in directory. Another notable point is that assemblies used by several applications on a machine should be stored in the global assembly cache. If an assembly will be stored in the global cache, the assembly must have strong names.

Now let’s look at a breakdown of the differences between .NET components and COM components.

After this comparison, it looks like .NET has all the benefits of COM, without the hassles. Some of the characteristics might not seem to be a big deal, but others, such as not having to register your managed components, take a huge burden off the developers.

Granted, there are still circumstances in which you have to register your component.We’ll be covering this in the next section.

Using Interop to Work with Unmanaged COM Components

.NET does provide a way for managed code to work with unmanaged COM objects. If you are looking to use a COM component in your .NET project, you must use the COM Interop utility (TlbImp.exe) for importing the COM types. This exposes the necessary interfaces to allow them to communicate with each other.

If you want to use your .NET components in an unmanaged project, you can do so with a few extra steps. You need to mimic a typical COM object and how it operates. To do this, use RegAsm.exe. This does two things. First, it exports the managed types into a type library. Second, it puts the information in the registry, as with all other COM objects. This gives your .NET component the capability to imitate a COM object. Otherwise, there is no bridge to communicate from the unmanaged process to the managed process.

COM Component Issues

Surely you have run across one or more of the following issues when trying to debug a new or changed COM object. We’ll tackle some issues and solutions here.

Security Issues with Components

You should be asking yourself some common questions when working with any component:

• Where is the component running? Is it local or on a remote system? If it’s remote, is the component configured properly to run on the remote computer?

• Is the component accessing other services of the operating system or network? Does the component need to write a file to a directory that has been secured to only a specific group or user? Are you trying to create a network connection to another computer?

• When the component is running as a service, who is the component logged in as? Does the login have all the rights to perform the needed tasks?

One of the annoying tasks of working with COM components is keeping track of references made to the component and making sure that you clean up and release any memory or objects you that have used. This is no longer an issue in the .NET framework because memory management is handled for you.

.NET Components

Microsoft has taken some of the nifty features of Visual Basic and carried them over to the .NET framework. One of these features is memory management. You no longer have to release or dereference your components because the garbage collector will handle it for you.

Garbage Collection

Garbage collection is not new to Visual Basic, but it is new to C#. Although the previous versions of garbage collection might not have been as robust as desired, it looks as if Microsoft has enhanced the process of cleaning up.

The Registry

Now with .NET there is no need to register your component in the registry to use it—with one exception. If you plan to have an existing COM component or a new COM object call in your .NET component, you will need to register your component with the registry. This way, the other COM objects know how to communicate with your component.

Installing a .NET Component Versus a COM Component

One of our favorite things about .NET is how to install and upgrade components. Unlike installing (or, even worse, upgrading) a COM component, this process is simple and straightforward.

So How Do You Install a New .NET Component?

You no longer need to use Regsrv32.exe for .NET components, but you still need to use it for COM components. The only thing that you need to do to install a new or updated version of your .NET component is use Xcopy.exe or your preferred method of copying a file from one location to another. .NET components are self-describing; when a component is running, it makes a copy of itself. Thus, you can copy right over the old version without having to deal with the file being locked by another user because it is in use at the time.

Uninstalling Components

Typical problems with COM components have to do with upgrading them. This involves deregistering the COM object and then deleting it to replace it with the new version. To do this, the COM object typically needs to be deregistered and removed from memory. To do this, you’ll end up restarting the web service or computer, depending on what the COM object is being used by.

Another annoying issue is that you must execute this on the computer on which the component is installed. This usually means that you have to be logged onto the system or must be using some sort of remote-control software.

Well, you can kiss all these problems goodbye. Microsoft has finally given you a way to get around these problems. Now the only thing that needs to be done is to copy the new component to your in directory, essentially overwriting the old component (assuming that one already exists) and replacing it with the new one.Wow! That wasn’t very hard. Because the system will detect that the component is newer, it will release the old copy and load the new version into memory. Presto, change-o—now your system is running with your new component. No need to deregister the old component and register the new one. It couldn’t be easier.

One thing to keep in mind is that this technique applies to managed components only. If your component is using the Interop namespace because it needs to simulate a COM object, then you will still have to register your component in the registry as you would any COM component.