[wix-users] Burn Related Bundle doc

Thu Jan 26 06:07:05 PST 2017

I'm glad to help, as many here have helped me. <smile/>

Since you have implemented a custom BA, then you might need to implement code in DetectRelatedBundle handler.  Here is the code I am using, which I am sure is driven in part by my business rules (as dictated by the marketing guys).

        private void DetectRelatedBundle(object sender, DetectRelatedBundleEventArgs e)
        {
            using (new ActivityTracerScope(mba.TraceSrc))
            {
                //MyNamespace.UX.InstallationViewModel.DetectRelatedBundledDumpArgs(e);

                if (e.Operation == RelatedOperation.Downgrade)
                {
                    this.Downgrade = true;
                    mba.Model.Wix.Engine.Log(LogLevel.Debug, "Detected a relative: Operation is to downgrade");
                }
                else if (e.Operation == RelatedOperation.MajorUpgrade && mba.Model.BundleTag.Equals(e.BundleTag, StringComparison.OrdinalIgnoreCase))
                {
                    // Used in DetectComplete to implement certain business rules
                    mba.Model.IsBundleMajorUpgradeDetected = true;
                }

                if (RelationType.Dependent == e.RelationType)
                {
                    // Used in DetectComplete to implement business rules such as blocking if a required configuration is not detected.
                    mba.Model.DependentBundleDetected = true;
                    mba.Model.DependentBundleTag = e.BundleTag;
                }
                else if (RelationType.Update == e.RelationType && e.Operation == RelatedOperation.None)
                {
                    // While this is a dependent bundle we don't need to set the above flags to use this flag. (and should modify related code if they are set)
                    // Use this in DetectPackageComplete to detect when to avoid uninstalling a certian package which is included in multiple bundles, after it was successfully upgraded.
                    mba.Model.DependentBundleOpNoneDetected = true;
                }
            }
        }

        private static void DetectRelatedBundledDumpArgs(DetectRelatedBundleEventArgs e)
        {
            mba.Model.Wix.Engine.Log(LogLevel.Verbose, string.Format(CultureInfo.CurrentCulture, "Detect a relative: Tag: {0}, Operation: {1}, Machine: {2}, Code: {3}, Relation: {4}, result: {5}, version: {6} ", e.BundleTag, e.Operation, e.PerMachine, e.ProductCode, e.RelationType, e.Result, e.Version));
            return;
        }

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Orzyszek Andreas <Andreas.Orzyszek at dentsplysirona.com>
Sent: Thursday, January 26, 2017 3:38:16 AM
To: 'WiX Toolset Users Mailing List'
Subject: Re: [wix-users] Burn Related Bundle doc

That was a lot of information.
I just want to give thanks for this.
I am sure I'll get it to work after knowing the right direction.

And I use a CustomBA because marketing guys always want fancy UIs :-)

Andreas

-----Ursprüngliche Nachricht-----
Von: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] Im Auftrag von Phill Hogland
Gesendet: Mittwoch, 25. Januar 2017 16:16
An: 'WiX Toolset Users Mailing List' <wix-users at lists.wixtoolset.org>
Betreff: Re: [wix-users] Burn Related Bundle doc

I don't know of additional documentation for RelatedBundle element, other than studying the WixStdBA code.  You might find that searching the old wix forums on nabble.com to be useful

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/

<http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/>I would not post anything to those old forums and would focus on the wix-users subforum, but the wix-devs subforum might have something helpful.

I have not used the 'Upgrade' option, but I use both the 'Addon' and the 'Patch' options, along with 'Detect'.  (It sounds to me like your trying to do a 'Patch' option, with some caveats explained later.)

1) I always define a 'RelatedBundle' GUID for each Bundle/product I author (using the same one from version to version, just like is done for the UpgradeCode).

2) In every bundle I create I include 'Detect' statement with that bundle's RelatedBundleCode.  this provides a hook to allow a future deployment of a related bundle which targets this bundle.

<RelatedBundle Action='Detect' Id='$(var.ThisProduct_RelatedBundleCode)' />

3)  If I am just rolling a new version of this bundle, I make sure that the bundles version is incremented and the chain remains the same (or is changed to reflect changes to the product with each MSI following the MajorUpgrade rules.  In this case I do not need to do anything more with the RelatedBundle element to effect a major upgrade.  But the key is to make sure that the bundle's version is always incremented for each and every build.

4) If I wanted to create a new bundle (not just a new version of the same bundle) and as you indicated I want to deploy only an updated MajorUpgrade MSI (or a msp) for one of the MSIs in the base product's chain, then in the NEW bundle, with a different UpgradeCode, I would author:

a) The 'Detect' for the New Bundle - just because I always do this in case I need it in the future.  You may not want to do this

b) Then I assign a 'Patch' action RelatedBundle with the UpgradeCode of the targeted base bundle.

<RelatedBundle Action='Detect' Id='$(var.NewPatch_RelatedBundleCode)' /> <RelatedBundle Action='Patch' Id='$(var.BaseProduct_UpgradeCode)' />

5)  In my products we deploy a base-suite of applications and servers, and then we have several 'optional' applications or servers which are only used (or offered too) certain market groups.  In this case I use the 'Addon' action.

    <RelatedBundle Action='Detect' Id='$(var.ThisAddon_RelatedBundleCode)' />
    <RelatedBundle Action='Addon' Id='$(var.BaseProduct1_UpgradeCode)' />
    <RelatedBundle Action='Addon' Id='$(var.BaseProduct2_UpgradeCode)' />

In the above case my 'Addon' can be applied to either of two different base configurations.

If you are writing a custom BA, then you will want to look at the RelatedBundle handlers and you may need to implement some special logic, but I found that in most cases the default behavior seemed adequate.  While I have not used the WixStdBA, since I started using ReleatedBundle elements, from looking at the code it seems to have robust support of RelatedBundles and is a good place to start in studying the intended behavior.

Phill

________________________________
From: wix-users <wix-users-bounces at lists.wixtoolset.org> on behalf of Orzyszek Andreas <Andreas.Orzyszek at dentsplysirona.com>
Sent: Wednesday, January 25, 2017 1:40:54 AM
To: 'WiX Toolset Users Mailing List'
Subject: [wix-users] Burn Related Bundle doc

Hi,

I am searching for documentation related to the <RelatedBundle> Element.
On the website I only found the possible values for the action attribute.
These are: Detect; Upgrade; Addon and Patch.

Dectect just checks if a related bundle is present and the fires a special event in the detect phase.
I don’t understand the other 3 at the moment.

Let’s say I have a bundle with version 1 (B V1) and the bundle installs 2 msi packages P1 V1 and P2 V1.
The <RelatedBundle> Element is present and the action is Upgrade.
Now I create bundle version 2 (B V2) the bundle upgrade code is the same but I only want to include the msi package P1 V2.
The package upgradecodes also match. I just want to skip the P2 package because nothing changed there.
I think I could just include P2 V1 with the new bundle but omitting it will save tons of size and download traffic.

If I run the B V2 install B V1 will be uninstalled with both packages P1 V1 and P2 V1. Then B V2 will be installed with only the P1 V2 package.
So I just lost package P2 V1.

Not sure if such a szenario is support. If someone could hint me to some more doc about this, it would be helpful.

Thanks

Andreas

-----------------------------------------------------------------------------------------------------------
Sirona Dental Systems GmbH • HRB 24948 • Vorsitzender des Aufsichtsrats: Dr. Erich Blum • Sirona Dental Services GmbH • HRB 25817 •
Geschäftsführung: Rainer Berthan • Michael Geil • Sitz der Gesellschaften: Bensheim • Registergericht: AG Darmstadt •
------------------------------------------------------------------------------------------------------------
Diese E-Mail ist ausschliesslich fuer den angesprochenen Adressaten bestimmt und kann vertrauliche Informationen beinhalten.
--
This e-mail is intended only for the designated recipient(s). It may contain confidential or proprietary information.
------------------------------------------------------------------------------------------------------------

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/

-----------------------------------------------------------------------------------------------------------
Sirona Dental Systems GmbH • HRB 24948 •
Vorsitzender des Aufsichtsrats: Dr. Erich Blum •
Sirona Dental Services GmbH • HRB 25817 •
Geschaeftsfuehrung: Rainer Berthan • Michael Geil •
Sitz der Gesellschaften: Bensheim • Registergericht: AG Darmstadt •
------------------------------------------------------------------------------------------------------------
Diese E-Mail ist ausschliesslich fuer den angesprochenen Adressaten
bestimmt und kann vertrauliche Informationen beinhalten.
--
This e-mail is intended only for the designated recipient(s). It may
contain confidential or proprietary information.
------------------------------------------------------------------------------------------------------------

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/