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. The cache is there for good reasons and has significantly reduced the failure rate, but for people with smaller system drives or partitions it can be a barrier. Deleting the cache directory in its entirety can also lead to problems.
So a design change was made to the WiX setup chainer, Burn, to support setting a registry-based policy to redirect the cache to another partition. This registry policy defines the root directory for the Package Cache and affects all newer bundles after the registry value is set. Both newer and older bundles – because older bundles do not have this feature – will fall back to the default location in “%ProgramData%\Package Cache”.
Setting the registry policy
To set this registry policy for per-machine bundles, open an elevated command prompt and run the following command.
reg.exe add HKLM\Software\Policies\WiX\Burn /v PackageCache /d X:\PackageCache
Replace X:\PackageCache with wherever you’d like the cache to be rooted.
The DACL on this directory will be secured each time a bundle begins to cache payloads. You should only do this once because Burn will not track each location you’ve set previously. If you need to later change the directory, copy the contents from the previous redirected cache location to the new redirected cache location with security intact, like so:
robocopy.exe /copyall /e X:\PackageCache Y:\PackageCache
Replace X:\PackageCache with your previous redirected cache location and Y:\PackageCache with your new redirected cache location.
Never move the packages from the default cache location “%ProgramData%\Package Cache” because some bundles will only check that location and will either fail to install, or will download the payloads again thus consuming more disk space.
The change to support registry-based redirection of the Package Cache shipped in Visual Studio 2013 Update 4, Visual Studio 2015, and newer; and the public release of WiX 3.9. Note that with VSUpdate, any patch packages may be cached in the new location but the product packages they target will remain in the default location. Major upgrade packages within VSUpdate will also be in the newer cache location unless already installed by some other means: for example, a pre-release of VS2015 that ships some shared packages with VS2013 Update).