Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Parallel installs


4 replies to this topic

russellperry

russellperry
  • Full Members
  • 31 posts

Posted 22 December 2005 - 16:04

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

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 22 December 2005 - 17:23

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

russellperry

russellperry
  • Full Members
  • 31 posts

Posted 22 December 2005 - 19:32

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

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 23 December 2005 - 08:40

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.
Regards
-Stein Åsmul

chrpai

chrpai
  • Full Members
  • 26 posts

Posted 06 July 2006 - 00:15

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.

Christopher Painter, MCSE
Author of:
DeploymentEngineering.com
MSI Factory Provider for ADO.NET 2.0 (Work In Progress)
99 Bottles Of Beer - Windows Installer

PM for personal communication only. Please ask questions in the forums.