4 replies to this topic

[russellperry]

Pretty straightforward question: my company would like to change our install to allow for multiple versions of our product on the same machine, with upgrade paths for the major versions, in different folders, "program files\MyProduct5," "program files\MyProduct4," etc. We also would like to keep the entire image of a given version within one folder, minimizing shared resources in System32. Some shared components are inevitable, but most of the dlls, bpls, and COM controls are proprietary, and will be stored in the project directory.

The problem is, these product versions use many of the same files, some of which will have different versions some won't, across two different product versions. The docs seem to indicate that identical files/resources cannot be in different components across companies, not just products.

Must I use a common directory, like System32, for all shared components? What if the version of one of these shared components changes for a given version? Particularly for the activex controls, some of which will have version changes for the same upgrade path -- can I not have the same version of a resource installed for two different products in two separate folders in two different components/GUIDs? Will the identical COM registration entries for the same version of ActiveX in two directories cause conflicts between the two products?

[Stefan Krueger]

"identical resources" includes the path. So you can install files with same name to different directories with different ComponentIds.

[russellperry]

Brilliant, thanks so much for clearing that up. I read the MSDN docs numerous times, but some of the documentation seemed to be ambiguous on that point.

I'm still wondering, though, whether registration for identical COM controls violate the "same path" criterion? Won't two identical COM controls generate numerous identical registry resources, even if the controls themselves are on different paths?

[Glytzhkof]

Remember the golden rule of MSI: There should be a 1 to 1 link between an absolute path (with file name) and a component GUID. This means that you should never have two GUIDs pointing to the same absolute path, and you should never refer to the same absolute path with several GUIDs. This means that if you install the same files to a different folder you should change all component GUIDs. You should also change the product code, package code and possibly the upgrade code (the latter depends on how you want upgrade scenarios to work).

As to COM servers: COM servers are registered per machine for a per machine install. This means there can be only once registration for any COM server that references the same registry keys. This means that your COM component will be initiated from the last location it was installed. IT is possible to work around this by using the isolation feature of Windows Installer. U can look this up in the SDK.

[chrpai]

How is this supposed to work with merge modules that support retargettable directories? It seems like you could quickly get in trouble if different vendors or even different product teams from a single vendor consume merge modules and deploy them to different directories.