[wix-users] Advice needed

[Phill Hogland]

I am relatively new to both also, having started down the path of converting years of legacy setups about two years ago.  The approach, advised here by some, which has worked well for me is to stick to MajorUpgrades, but create a Burn driven bundle of chained MSIs, which are small and contain the functionality of a product's "feature" ( an application or group of functionality).  I divided the significant groups of applications into individual MSI packages (without any UI).  The Bundle has the UI, and controls which packages are installed, etc.  I do not try to select MSI 'Features' per say.   The default  WixStdBA can be used, but eventually I developed a managed BA using the WixBA in the wix source code as an example project (although it is not a tutorial).   The WixBA is also an example of using Web-deployment with packages which are built as part of the bundle chain, but are staged external to the bundle on a web server.  The web-connected user only needs to download the bundle (~1mb).  For an isolated deployment the Burn -layout switch is used.  So for an 'upgrade' I just build and stage a new Major Upgrade of the bundle and each MSI package that is related to the bundle.  If a particular MSI package did not have changes it is still part of the build and staging.  At install time the Burn bundle knows to download only the packages which aronly needs to update on package in the chain, or is a first time install.  It also does not download platform specific or locale specific packages if not needed.    Most of these ideas came from studying how the Wix Toolset team structures the wix\src\Setup projects in the source code and from blogs like:
http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/
http://stackoverflow.com/questions/11572508/how-to-do-major-upgrades-when-using-burn-wix-3-6

And from searching the old wix forums (which remains a good silent resource to search)
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/

Also I use the RelatedBundle element to create an 'addon' bundle that has another MSI package that is only needed to be added into the base package for certain business situations.  In a similar way one can create a related bundle that has your minor upgrade/patch, and deploy it as a ReleatedBundle "patch" to the base bundle (although I have not done this yet as I am not ready to figure out all of the issues related to minor upgrades or patching).  To allow me to do this at some point in the future I add the following to each bundle I currently ship.
<RelatedBundle Action='Detect' Id='$(var.ThisBundle_RelatedBundleGUID)' />

Then if I decide to create an 'addon' the new bundle will have something like:  (or similar variant for a patch)
<RelatedBundle Action='Addon' Id='$(var.BaseBundle's_ RelatedBundleGUID)' />

-----Original Message-----
From: wix-users [mailto:wix-users-bounces at lists.wixtoolset.org] On Behalf Of Yavor Ivanov
Sent: Saturday, November 14, 2015 9:45 AM
To: wix-users at lists.wixtoolset.org
Subject: [wix-users] Advice needed

Hi all!

I am new to WiX and windows installer stuff in general :) I am developing an application and need advice how to plan for updates. Here is my case. I have an application that is around 10mb. Apart from the main application I have around 60 mb of content. I have created a setup that installs it all.
So far so good. But now comes the tricky part. The application is far more volatile than the content. Bugs get fixed, new features are introduced. I want to make it easy on the end users and not make them download the entire 70mb installer every time I fix something. The content is far less likely to change than the application. Can you advice me what's the best way to have a single installer for the application and content, while allowing the user to update the application and content separately? For the content I can use minor or small updates, while for the application I plan using only major updates.

Regards,
Yavor

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