Web setup feature

Apr 10, 2016 at 9:53 PM

i want one platform neutral setup and reference either x86 or x64 setup depending on some OS feature remotely.
Both platform dependent setups are hosted on a webs server or FTP.

if (some feature x86) then
download x86 msi ans execute (containing x86 platform specific files)
download x64 msi ans execute (containing x64 platform specific files)

Is this possible by now?

Apr 11, 2016 at 2:31 AM
Probably you already aware that MSI doesn't support "platform neutral setup". It's a shame but nothing we can do about it.
My immediate intuitive answer to this requirement is to build a bootstrapper containing both MSIs and launch one or another depending on the runtime condition. The Bootstrapper sample demonstrates how to analyse the registry and set a session variable (property) to the value that would reflect the analysis result. After that you can make your two packages subject to the condition based this variable value.
Apr 11, 2016 at 12:17 PM
Hi Oleg,

and what about downloading them from internet? Custom dialog for WiX or custom UI setup with custom code behind, or?

Apr 11, 2016 at 12:37 PM
As for me I would go with... custom Bootstrapper or an external custom UI as in the External_UI sample. These are the reasons:
  1. Using custom dialog would require the MSI host to be built and run in the target system but the MSI needs to be downloaded. It's kind of a chicken/egg chellenge.
  2. Custom_UI also need to be hosted by MSI. So it is the same as #1
  3. Custom bootstrapper app is a good one but in order to build it you need to bundle it with some fake package. And even if you do so then you need to fool Burn runtime during package scheduling. However you probably can create a custom Web package (similar to .NET webInstall). If you can manage this then it would be an ideal solution. Though I never tried this and not sure what is involved.
  4. You can build your completely decoupled free standing bootstrapper (External_UI) and use it to download the msi (easy done with System.Net) and start it (with Process.Start). While it seems like an alternative to #3 but it is actually the same concept. Simply #4 would be your own very domain specific solution with no constrains and #3 is a WiX generic solution with a strict runtime interface you need to adhere to. But MSI runtime will see them as just another external UI.
Apr 12, 2016 at 1:15 PM
After some more consideration I think I overlooked something very obvious.

Create a custom very simple downloader app:

static void Main(string[] args)
    if(args.First() == "/i")
        string url = "http://mycompany.com/my_x86.msi";          
        string file = Web.Download(url);
        Process.Start("msiexec.exe", "/i \""+ file+"\"").WaitForExit();
         Process.Start("msiexec.exe", "/u <your product GUID>").WaitForExit();
And now in define your bootstrapper:
 var bootstrapper =
        new Bundle("My Product",
            new PackageGroupRef("NetFx40Web"),
            new ExePackage("my_web_setup.exe")
                Id = "package1",
                Name = "MySetup",
                InstallCommand = "/i",
                UninstallCommand = "/u"
                DetectCondition = "MY_PRODUCT_DETECTED",
                Permanent = true,
And of course you will need to set up reading your product key from registry into MY_PRODUCT_DETECTED. For that you will need to use UtilRegistrySearch class (see WixBootstrapper sample).
Apr 12, 2016 at 3:06 PM
Hello Oleg,

thank you very much for your tip!

But why i cannot use the "DownloadUrl" attribute of the <MsiPackage > element of a bundle?

Apr 13, 2016 at 12:59 AM
> But why i cannot use the "DownloadUrl"

You can. I just didn't considered it. :)
It seems even a better and more natural approach. You will still need to do the magic of with detecting your CPU architecture and trigger one or another MSiPackage execution. Unfortunately the actual URL has to be hardcoded and only payload IDs and file names can be substituted at runtime.

In addition to this I just though about anoter interesting opportunity to simplify the whole solution. You can hav a simple URL based MSiPackage wraappeed into a dumb bootstrtepper and let the web serer hosting the downloadanble MSIs to decide which one to return on HTTP request. You can analyse the On the server User Agent of the request and detect if it came form x64 machine or fro x86 and return the correct msi. But you will need to test it first to see if Burn built in downloader properly includes the client OS info into request.
Apr 13, 2016 at 3:29 PM
Is the MSiPackage element wrapped by your librraries? Can i use it in C#?

Maybe i'll play a little with the MSiPackage element. This has seemed to me like a more generic solution.
Otherwise i probably choose a custom UI setup.

Apr 14, 2016 at 2:13 AM
> Is the MSiPackage element wrapped by your librraries?
Of course. Have a look at <Wix#>\Samples\Bootstrapper\WixBooststrapper samples.