What are limitations of side-by-side COM?

Question

We need to adapt our application to be usable through ClickOnce. The application consists of a .exe file, and a huge set of Visual C++ libraries, some of them are in-proc COM servers used by other libraries.

Currently our installer does regsvr32 to register the COM servers, but looks like ClickOnce applications are not allowed to modify the registry during installation. So we need something else.

Option one is to remove CoCreateInstance() and instead use LoadLibraryEx()/DllGetClassObject(). This will require code modification, but is very reliable - I don't see any reason why this wouldn't work.

Option two is to use side-by-side COM activation with manifests. The problem I see immediately is that we increment the version number in each nightly build, so we will have to update manifests automatically. That's not very inspiring. What are other not so obvious limitations of using side-by-side COM activation?

Answer 1

The advantage of side-by-side COM is that it solves your problem without any code changes -- it's possible to retrofit side-by-side COM to a set of existing COM components.

The downsides:

• Side-by-side is not a widely-used technique (outside a couple of components such as the VC++ runtime library and Windows Common Controls, which don't use COM), and it takes some effort to find troubleshooting information on the web
• If you're on XP or Server 2003 then you get no help from the OS when things go wrong. In particular, XP gives misleading messages in the event log; 2k3 is better. Vista and above give you the sxstrace tool.
• You'll need to maintain manifest files in parallel with the components themselves. In many respects, the manifest files duplicate information already in type libraries. Whereas you can maintain these by hand (they're XML files with a reasonably simple schema), you might want to re-generate them each time you do a build. This takes care of the versioning problem.