COM components such as ActiveX controls must be registered when they are installed to allow applications to use them. The Microsoft development environment will do this automatically for any ActiveX components you include in your setup distribution unit. When the component is uninstalled with the setup distribution unit, the setup removes the component from the registry.
Windows keeps track of the number of setup programs that have installed the same component. The component is only removed when all the applications using it are uninstalled. The counting of these applications per shared COM component is based on the absolute path of the file. It is important for such components to be installed in the same folder by all applications that include them.
The Microsoft development environment provides a means of installing such COM components in the Windows System folder through a setup distribution unit so they can be shared between applications. For step-by-step instructions, see Installing Shared Files in the System Folder.
The count of the applications using the component is based solely on the location of the file (the absolute path of the file) and not the CLSID (class ID) of the component. It is good practice to change the name of the file if the CLSID of the component ever changes, or it is possible to leave entries for the old CLSID in the registry that point at a file that can no longer create that component.
For DCOM components, the Microsoft development environment setup distribution unit provides a means to install references to remote DCOM servers by including the .vbr and .tlb files (created by Visual Basic and Visual J++ when they build remote servers). You would want to do this if your application used a central server — for example a bank account server that provided access to a user's bank account details. Centralizing the access to sensitive information like this behind a server provides a more secure system, because the only access to the data is through the server.