Visual Studio 2012 installation constraints

Question

When attempting to install Visual Studio 2012, I noticed that it needs to consume a significant portion of my boot disk as a pre-requisite to installation:

It needs more than double the disk space on my boot drive than the directory where it's going to live! What is this madness?

Doing some searching, I found a user with a similar issue, but he was only able to remedy his problem by un-mounting all the extra drives, then launch the installer. Presumably, he had an OS on the drive he wants to install to. I do not. (And don't want to, either). His predicament is outlined here: https://stackoverflow.com/questions/14466787/why-does-visual-studio-install-onto-multiple-drives

Per the suggestions in the question above, I moved all my "temp" directory references to point to the "E:\" drive to try and force it off "C:\", as such:

But no dice. It's documented that files are only temporary; If that's the case, why does it insist on putting loads of files onto my boot disk? I'd be alright with this, except I don't have 6 gigabytes to spare for this installation, and can't free enough up to let it do it's thing. This disk is from the early stages of consumer SSD's, so the pickins' be slim, and that's OK because I never meant it to house space hungry applications.

Is there anything I can do, short of extending the disk, or absurdly uninstalling a bunch of other applications, installing Visual Studio, then reinstalling the other apps? This is a particularly frustrating problem considering I've got terabytes of space to work with on the other drive ;)

Answer 1

I ended up reclaiming a significant portion of my boot drive by using the DISM (Deployment Image Servicing and Management) utility included in Windows 7: DISM Utility Specifically, I ran the DISM tool with the following arguments:

>dism.exe /online /cleanup-image /spsuperseded

Presumably, Windows is storing the uninstall information for the service packs and updates, which hogs a lot of room. By "locking" myself into the current service pack, I was able to free up 6+ gigs of room on the system drive. If this were a critical production machine, I'd be a bit more concerned, but since my machine is essentially a low impact home machine, there's no reason to keep the old service pack files around.

This doesn't solve the initial problem, however, but I thought this was a useful tip for anyone looking to reclaim space from a more "obscure" method. Cheers to Ken White for his insight, and I hope this information can help someone else along the way.