One of our applications needs to register a COM control during installation. If a newer version of that control is already registered, we don't want to overwrite it with the older. What are the Windows MSI install conditions I would user to control this? Or is there some other 'best-practice' method I'm not aware of?
Thanks
Sounds like your main problem is that you have two controls that support the same CoClass's, but live in different file paths. That's not a great situation to be in. If at all possible, there should only be one possible file path for a binary that implements a particular COM class.
That way, file versioning rules will make sure that the latest file is installed by MSI installers. MSI won't by default overwrite newer file versions with older ones.
There are applications out there that have the problem that customers need to use the older version of a class occasionally while still having the newer version installed and available. One solution is to have a utility application that the customers can run that will "point" the COM registry entries to the correct binary.
There are definitely permissions issues with implementing that correctly on non-administrative accounts and you should avoid putting yourself in that situation if at all possible.
If you absolutely must have multiple binaries implementing the same COM CoClass GUID and if it is not too late to change old clients, you could create a master "factory" class that takes whatever data/info is available from the client and chooses the correct implementation to return. It would simply be a COM class with an interface that had methods that returned interface pointers to the actual interface the clients needs after allocating the proper implementation class and queryinterfacing for the client interface.
edit You may choose to change the location of your application from version to version (e.g. "c:\program files\My App V2". That's okay so long as you use the MSI product code and version #, etc. attributes of your packages to force MSI to uninstall any existing versions of your application before installing new ones.
What you are missing here is merge-modules. Basicly you create a merge-module for your COMxx component. This gets recompiled with each new version 19, 20, 21, ... of your component (but keeps its GUID). Both your applications "reference" this COMxx merge-module and ship its content to the user.
This way windows installer will make sure your dll is refcounted and upgraded only if needed, provided you maintain (increase) version info in your dll.
Edit: The merge-module also hard codes install path, which usually ends up somewhere in C:\Program Files\Common Files\{My Company}\{My Component}, both applications ship it there.