In that situation, and assuming you have a robust file versioning scheme, in all these cases you go ahaead and install the MSI anyway and:
1. Package versions of those files that have lower file versions and will therefore not update the existing higher versioned ones.Apply component rules, and they should be in a common container (such as a merge module) to make sure that you do follow those rules. or 2. Have those files in a feature in their containing MSI and ensure that the feature is not installed (with INSTALLLEVEL perhaps) if that other product is detected. or 3. If the number of files is not cumbersome, make each containing component transitive and dependent on the upgrade detecting an older product. You'll need to re-evaluate the component condition at every operation (such as repair) to ensure those files are not potentially overwritten. This has the potential advantage that if if the other product is uninstalled and you now need those files then a repair would install them. --------------- Phil Wilson On Tue, May 19, 2015 at 9:04 PM, Rajesh Nagpal <rnag...@microsoft.com> wrote: > Ok Let me try this time to state the problem:) > > We have a legacy setup installer(based on wix 3.0) that installs the "core > engine" features. We are developing a new setup installer(based on wix 3.8) > that installs "tools" features. Based on the current code they both share a > common msi(which is actually an engine msi but contains some of the tools > binaries), so I need to package that msi in our "tools" installer but we > also don't want to accidently update the "engine" components as we rev the > "tools" installer more frequently. So I want to detect this condition and > block the setup. We are working long term to fix this correctly by > refactoring the code but need to have this check meantime. > > Let me know if that makes sense now for the problem I'm trying to solve. > > We don't plan to move to Wix 3.9 very soon just because of the ProductSearch > feature since we have a workaround for it but yes, I'll update this logic of > doing registry checks once we move to win 3.9 or higher. > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Getting-ProductVersion-of-an-msi-from-wix-tp7600320p7600377.html > Sent from the wix-users mailing list archive at Nabble.com. > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
