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 – when attempting to restore the machine to the state it should be in (according to that package and any patches applied to it).
When the WiX community was developing Burn – the chainer that is part of the toolset in v3.6 – we knew this was a common problem for any Windows Installer-based deployment. So we implemented package caching which copies all installed packages to a fixed location depending on whether a package is installing for all users (per-machine) or just the current user (per-user).
Setup developers can opt in or out of package caching, but because we know customers have had problems with prompts for source we decided that the Visual Studio 2012 family of products will cache packages.
After packages are downloaded and verified, or when they have been verified on media, they are copied to the local hard drive. For packages installed per-machine, this is a secure location and is actually the location from which the installation occurs.
When repairing, modifying, or uninstalling a product or when installing or uninstalling a patch, if source media is required the package cache is used automatically and most users will never see a prompt. Only if the package cache is missing or incomplete will Visual Studio setup will prompt to download (if connected) or locate media as shown in the screenshot below.
Users who have installed from media even get the option to download (if connected). So while very few customers should ever see this dialog, we wanted to make sure the experience was easy.
Even though we will prompt to download packages to the cache if missing, we recommend users do not remove the package cache. Not only is the cached used by any other products that are installed with Burn and may not provide the same download experience, there are scenarios when Windows Installer may require source that we cannot handle because our code is not running.
Impact to Drive Space
The design to avoid this all too common problem does have an impact to drive space. For per-machine installs like Visual Studio 2012, packages are copied under
%ProgramData% which is, by default, on the system drive. This is one of several reasons that VS2012 requires space on the system drive even if you install VS2012 to another drive.
From customer data we know that:
Over 97% of customers have plenty of space on their system drives to install all of our largest product, Visual Studio 2012 Ultimate, entirely on the system drive.
Over 99% have sufficient space on their system drives to install other products like Visual Studio 2012 Express for Windows 8 entirely on their system drives.
Nearly 100% of customers have sufficient space on their system drives to install Visual Studio 2012 to another drive even though some space will be consumed on the system drives.
In general, we do not recommend "system partitions". We understand developers may like to keep source, binaries, and even tools on a separate drive – it’s a common setup – but the system drive should never be so constrained that updates – even to the operating system – cannot be installed. Many common locations default to the system drive and some of those cannot be changed. Give your system partition plenty of space.