About Windows Installer, the .NET Framework, and Visual Studio.
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.
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.
@Rahul, VS2013 and future versions all use the same package cache, as do any other bundles that use WiX Burn.
VS2013 and future versions..............
so, package cache created by VS2012 is irrelevant here?
Wow how completely obnoxious and typical of MS.
How about just giving me the damn option to control where that package cache is installed and stop forcing me to do it 'your way' ?
This blog summarizes exactly what is wrong with the Visual Studio development team, and why it took you over 20 years to make a settings dialog with over 200 different options re-sizable..
> The majority of drives in the first search results are 120GB or greater, and that's prior to any filtering.
I have such a disk. "120 GB" (120 × 1000³) translates to 111.7 GB (111 × 1024³), and you’re currently using 5.1 GB of it. That is 4.5% of my system disk for data that 99.999% of the time just LIES there.
But now to add insult to injury, you tell me that I only fail to realize that this is actually a good thing and the perfect design choice, not to give the user any control over that. I really wished I had your nerve. But I don’t work at Microsoft.