burn

I have a third party MSI that has been supplied to me by a vendor. However the MSI does not stand alone, it requires multiple support files (dll's, config files, device drivers ...) to complete an installation. I've tried to install without these files present in the directory with the MSI and it complains about the missing files during installation. Seems to me this is an odd way to build an installer. Anyway, I'd like to bundle this "installation" to be consumed by Burn. I've used MSIPackage before, but that works for a single file. How would I specify this group of files? I'm tempted to

In my managed bootstrapper, I'm packing Net framework 4.5.1 and VC Redistributable as follows: <PackageGroupRef Id = "NetFx451Redist" /> <PackageGroupRef Id = "VC_ReDist_120" After="NetFx451Redist" /> <RollbackBoundary /> <MsiPackage Id = "MainProduct" DisplayName = "$(var.ProductName)" DisplayInternalUI = "no" Visible = "no" Compressed = "yes" SourceFile = "$(var.MainProduct)" Vital = "yes" After = "NetFx451Redist" > On Windows 7 x64, where Net FW 4.5.1 is not present, by installing, this would display wixstdba's basic screen to install .Net framework and it also adds an entry in Add-Remove

Pitch I'm looking for high level advise on how to structure a WiX and Burn MSI based installer solution for an application suite. Question Given the layout below how many distinct MSI packages should an installer suite utilize when all apps/features and shared libs go into the same installation directory? One single MSI package for the whole suite is clearly too large (as shown by the current system) One (complete) MSI package per application would duplicate the dll libraries shared between the apps, which would mean a duplication of 100s of MB worth of DLLs. (Plus, to me, unknown headaches

How do I reference the RebootPending property in a Burn (WiX) bootstrapper? I know the property name is RebootPending, which is actually referencing the MsiSystemRebootPending property in Windows Installer. I'm currently trying something like this: <bal:Condition Message="There is a restart pending. Please restart your computer before attempting to install !(loc.ProductName).">RebootPending = 0</bal:Condition> But it's always true, even when Windows Update has just finished an update and needs to restart. Is my syntax wrong? Should my condition have [RebootPending] instead? Having been

I have a WIX_bundle (V1.0.0.0) which installs 4 third party MSI's of the version (5.0.0.0). Now the new version of my third party MSI's got updated (6.0.0.0). I created a new version of the WIX_Bundle with (v2.0.0.0) and both the WIX bundles have the same upgrade code. What I want to happen is that the new version of the WIX_Bundle should uninstall the previous version (v1.0.0.0 along with the 4 MSI's) and install the new version (v2.0.0.0 with new 4 MSI's). But when I try to install the WIX_BUndle V2.0.0.0, it tries to install the new version and is not doing an uninstall of the previous

Is it possible to somehow unpack a bundle? I need to make sure all packages within a bundle are signed correctly... TIA Dark.exe decompiles bundles; use -x to extract the bits. Run the installer with the argument -layout and it should download or extract (as appropriate) the packages that it contains to the directory the installer is in. You can specify a target directory as a second argument if you wish. This was tested with a bundle created with version 3.6.2520.0 . It is known to be broken on the current weekly release of wix36.exe itself. insignia will extract the engine. insignia -ib

I have a c++ application developed using Visual Studio 2015, along with a Wix installer and a Burn bootstrapper. Previous versions of the application were able to use the Visual Studio merge module to install the necessary prerequisites, but it appears that this isn't an option when using Visual Studio 2015 (see Redistributables for deploying C++ exe developed with Visual Studio 2015 on Windows 7 ). Following the advice in that link, we have started installing vcredist with Burn using an ExePackage with vital="yes". This mostly works great - we've had several customers who have the