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.
While I love the feature, Heath, and feel that it was necessary for the reasons you state, there is a growing segment of folks that wish to not have essentially three copies of any given installation on their system drive. With the advent of smallish SSD drive usage as system drives, the space requirements soon become an issue.
Windows Installer on x64 platforms stores the entire msi in its cache (which used to be stripped of cabs in x86), and now Burn's package cache, plus the installed bits, this now takes up almost 3x the space of the app itself on the system drive. Not having both cache paths movable is not only an oversight, but a mistake.
Thanks for dictating how I should use my SSD and my precious disk space. Your percentages means nothing when you truly screw over people in resource-constrained situations.
@Steven, SSDs were pretty small when they were first introduced but given the current state of the market and market trends with various other media introduced over the years of the PC, they should be sufficient now and will get better, of course.
The majority of drives in the first search results are 120GB or greater, and that's prior to any filtering.
As for the Windows Installer cache, I have several blogs on that as well. Yes, all MSIs are cached in whole on both x86 and x64 to support UAC correctly during repairs and uninstall; however, VS and the majority of products in Microsoft do not embed CABs in the MSIs. I've recommended to third parties that they do not embed CABs as well. All our CABs are all external, which is another reason we have switched to a robust chainer with a good download manager that our previous experience helped to design.
The space consumed, though, is not 3x the size of the product. VS2012 Ultimate sans the cache uses > 8GB. The cache on a full install (x64) < 1.2GB and the MSI cache is ~200MB.
Through many years of servicing VS, too many problems have occurred because of failed source resolution (and therefore prompting). Just take a look at blogs.msdn.com/.../searchresults.aspx for how many posts there are related to the topic.
If you're really concerned about that extra 1.2GB of storage for VS Ultimate (other products cache source as well) you can delete it if you know which directories to delete (all Burn package caches are flattened under a common directory; deleting the wrong ones can break other products) but it will be restored if ever needed so long as you're connected to the Internet or have media handy and you're running the Visual Studio setup (other products may not support that). An Internet connection will be required to restore update packages, though. If source is required and the media cannot be obtain, the scenario will simply fail.
I appreciate that disk space is an issue and for many years was on that side of the fence as well. But with the size of drives not only today but that have proliferated into the market over the last few years it has become less of a problem as our data and market analysis has shown. Missing source is one of the leading failures in Visual Studio setup and servicing and we're happy to provide customers relief from those problems.
At least that folder should automatically be compressed, since it's only being used once you install something and 0.0000001% of cases later on.
The space is limited when the VS2012 is in a VHD in itself, and you may want that vhd to be portable!
My Package Cache folder is 3GB, and the phone sdk smuggled in another several gigs under appdata. Am I doing it wrong?
@Gabest, no. The cache is often as big as the downloaded files, and Visual Studio is a large development environment. For Windows Phone SDK, the emulator is very large.
The 1.6 GB folder "C:\Users\All Users\Package Cache\" wasting precious space on my rather expensive 32GB SSD prompted me to uninstall all Visual Studio products from my machine. (Overreaction!) I simply can't afford to give up 5% of my SSD for a "better uninstall user experience".
However I can see now that I should have read this article prior to uninstalling... The ability to redownload the necessary packages from the internet is very nice. I could have simply deleted "Package Cache" and redownloaded the installer if I ever needed to uninstall Visual Studio in the future. Oh well...
@Daniel "3ICE" Berezvai, it's not just for uninstalls for servicing events as well - such as VSUpdate, which is bring customers both bug fixes and great new features.
Please note that the automatic download still requires that the bundle EXE is local (when launched from ARP) or you would have to re-download and execute it again from the web. But that is only when repairing the bundle. Packages are not automatically downloaded if a prompt for source should occur in another bundle (like VSUpdate).