[wix-users] dependent inistalls and use tracking
Phill Hogland
phill.hogland at rimage.com
Wed Mar 9 11:42:15 PST 2016
I concur, and would suggest that:
1) IF the shared components are going to be distributed for some other group to use in their MSI project AND you cannot control their tool selection, THEN that is when you might look at a Merge Module approach (as a least common denominator), otherwise the preferred approaches are:
2 -A) Shared Components, as others have described.
2-B) Use a WiX lib project
2-B-a) Default WiX lib without binaries, if building multiple projects with common authoring (which I find to be very handy for these situations), or
2-B-b) WiX lib with packed binaries, typically when you plan to give the common files to another group that is using the same version of wix toolset.
Generally I use 2-B-a to include the authoring for common component groups in different projects. The wix src\Setups has a wix lib project used in this way, and while last I looked I don't think that Components are defined in it, it has the common Directory tree authoring in it. I used to maintain a GUID "vault" common include file, which I still use for UpgradeCodes, etc, but generally for Components I use Guid="*" and let the compiler manage the GUID, rather than specifically author the GUIDs.
I'm sure there are other approaches and some will view the above comments as generalizations which depend on the specific needs.
________________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Edwin Castro <egcastr at gmail.com>
Sent: Wednesday, March 9, 2016 1:25 PM
To: WiX Toolset Users Mailing List
Subject: Re: [wix-users] dependent inistalls and use tracking
I'll bet that if you look closely at a verbose log you'll see that the
components for the tomcat files (assuming they don't violate the component
rules) do not get installed again when the second MSI is installed! In
other words, regardless of whether you use merge modules or shared
components as Wes describes, you should get proper behavior from the
Windows Installer if your components are properly constructed to follow the
component rules.
Since you have custom actions to perform the configuration and you
mentioned that the second install "wipes out the original configuration
settings" then that would indicate to me that main problem you have is that
the custom actions run on every install even if the configuration has
already happened on an initial install of a different MSI.
I would recommend that you evaluate your current merge modules to ensure
those components follow the component rules correctly and properly
condition your custom actions to execute only when the configuration is
desired.
--
Edwin G. Castro
On Wed, Mar 9, 2016 at 11:13 AM, Lewis Henderson <henderso at opentext.com>
wrote:
> Thanks for the reply, Wes.
>
> To answer your points (in reverse order):
>
> 1) No, this isn't an upgrade situation (yet). This is a set of new
> installs, but they may be upgraded at some point.
> 2) Yeah, I got the GUID typo...
> 3) Now the main bits...
>
> Do you mean use reference the tomcat component as a .wxi file? The merge
> module was set up to do much the same thing, but if they're obsolete... In
> any case, I'll give that a try. Yes, there are CA's run to perform the
> configuration, but I may be able to trigger them based on component install
> status. As long as the reference tracking realizes that the same component
> is in two different MSI's and doesn't install twice or remove too early,
> then I'm good. That's the problem I'm trying to fix.
>
> I'll let you (all) know what I find. Thanks again.
>
> Lewis Henderson
> OpenText, Inc.
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Wesley Manning
> Sent: Wednesday, March 9, 2016 1:22 PM
> To: WiX Toolset Users Mailing List
> Subject: Re: [wix-users] dependent inistalls and use tracking
>
> Also are you doing an upgrade on older versions or installing the products
> on a clean machine? If an upgrade then the majorupgrade element would
> affect things as well:
> http://wixtoolset.org/documentation/manual/v3/xsd/wix/majorupgrade.html.
> See the Schedule attribute.
>
> Wes
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Wesley Manning
> Sent: March-09-16 2:16 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: Re: [wix-users] dependent inistalls and use tracking
>
> Sorry by GUI I mean GUID.
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Wesley Manning
> Sent: March-09-16 2:15 PM
> To: WiX Toolset Users Mailing List <wix-users at lists.wixtoolset.org>
> Subject: Re: [wix-users] dependent inistalls and use tracking
>
> I don't know merge modules or tomcat but can speak in general. I don't
> think you need to be using merge modules for the common portion. Merge
> modules are kind of an old technology and temperamental from what I read on
> here.
>
> I'm assuming you have two MSI packages for A and B and they share
> components for C (i.e. tomcat). I would just put the shared tomcat files in
> a separate wix file and reference it from your A and B projects. As long as
> the GUI and install path are the same for each component you install then
> it should up rev the reference count and not reinstall the components. Do
> you have custom actions that you run as part of installing tomcat?
>
> Wes
>
> -----Original Message-----
> From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf
> Of Lewis Henderson
> Sent: March-09-16 10:12 AM
> To: wix-users at lists.wixtoolset.org
> Subject: [wix-users] dependent inistalls and use tracking
>
> Hi Folks,
>
> I asked a similar question a few days ago and got no response, so I'll ask
> again with a little more concrete situation.
>
> I have two product installs that both require an apache-tomcat install. I
> have no control of which product will be installed first, or if both will
> be installed. What I need is for both installs to be able to do an initial
> tomcat install, or if its already installed, not to install again (as that
> would overwrite the previous configuration settings). However, on
> uninstall, tomcat can't be removed until both products are removed, no
> matter which installed it in the first place.
>
> I have tomcat coded as a merge module which works fine for uninstall, but
> the second install does re-install tomcat and therefore wipes out the
> original configuration settings.
>
> I haven't delved into bundles, but the product installation UI's are
> pretty complicated, and tomcat may only be installed if certain features of
> one of the products is selected. Can a BA handle this kind of complexity?
>
> In any case, I need help to find a solution to this kind of situation.
> Please help me out here. Thanks.
>
> Lewis
> Henderson
> OpenText,
> Inc.
>
> PS: Yes, I need both products to use the same tomcat instance.
>
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-users
mailing list