Visual Studio can require a lot of space on the system drive, and previous methods of redirecting the Package Cache can be tricky for some people to set up or even maintain as junctions across volumes may be removed on boot.
Visual Studio can require a lot of space on the system drive. Based on years of data collected from customers’ installations from the Customer Experience Improvement Program, we took advantage of this feature in Burn – the Windows Installer XML (WiX) chainer – to eliminate most errors during repair,
The Windows Installer XML (WiX) team has released version 3.6 which, most notably, released a powerful and customizable chainer named Burn. The Visual Studio 2012 setup applications were built on Burn using features such as package caching, reference counting, and sticky patching to improve the overall experience from past releases.
Requiring source packages during installation, repairs, and even uninstall are common occurrences for some customers. The core issue is that Windows Installer needs the source location of the package and its files to install – and can’t find them automatically –
Slipstreaming Windows Installer patches is, technically, installing the MSP simultaneously with the MSI as a single transaction. This is, effectively:
msiexec /i D:\product.msi PATCH=D:\patch.msp
The applicable transforms (both the authoring changes and patch transforms) are applied to the MSI and the MSI is installed with those changes from the start.
On a day of many great Release Candidate (RC) announcements, I should not forget another important RC milestone: Windows Installer XML (WiX) v3.6 RC.
We’ve made a lot of improvements, simplified some scenarios, and fixed a lot of bugs. Download v3.6 RC and give it a try and let us know if you find any other issues.
There are times when repairing or servicing a product that source media is required. As more product installs move to web-based installs, these prompts for source are harder to solve. In order to replace missing, corrupted, or older files, the source is required because those files have to come from somewhere.
Late last week I checked in a feature for Windows Installer XML’s (WiX) chainer, Burn, that I’m really excited about (ask my colleagues): sticky patching.
This is a feature at the bundle (what we call our composition of packages for Burn) level that supports related bundles of type “Patch”
These days it’s more common to install products composed of more than one installer package. Modern applications are often a loose fitting of localized components and being authored into a single package just isn’t practical.
For example, a localized application will undoubtedly have neutral or single-language binaries while using satellite resources for other languages’
Now that WiX v3.6 has been released, I introduce the managed bootstrapper application (MBA) interoperability layer. It’s been available for a while actually, and if you’ve installed any builds of WiX v3.6, or the Microsoft Visual Studio 11.0 Developer Preview you’ve seen it in action.