There is a great article on MSDN by Dave Templin about new VS 2005 functionality that allows you to isolate COM components and avoid COM DLL hell. The technique only works on Windows XP though (see Limitations of Reg-Free COM). But what if you need solution now and your application has to run on earlier versions on Windows? Here is what you can do.
You only have to register your COM component if you want to be able to instantiate it using CoCreateInstance. However, if you are consuming your own COM components, you don't have to use CoCreateInstance. Here is how you can instantiate COM component without registering it in OS registry.
1. Locate COM component DLL.
2. Load it into memory using LoadLibrary.
3. Locate DllGetClassObject function exported from the DLL using GetProcAddress Win32 API.
4. Call DllGetClassObject and obtain IClassFactory interface of your component class factory. ATL automatically implements and exports this function for you.
5. Invoke IClassFactory::CreateInstance.
MSDN tells you not to call DllGetClassObject directly which is generally correct. However, if it is your own component and the component is native, the described technique will work. You can even maintain your own registry in a OS Registry subkey or in an external XML file. You can write MyCreateInstance that will be locating components by their CLSID in your private component registry and create object instances.
You can download Visual Studio SDK and discover that VS maintains its local component registry hive in HKLM\Software\Microsoft\VisualStudio\8.0\CLSID where it registers packages and other COM components. This allows different versions of VS to coexist on the same machine.
It is also possible to develop similar approach for COM components implemented in .NET but is a bit more complex.