Why Visual Studio 11 Requires Space on the System Drive

Why Visual Studio 11 Requires Space on the System Drive

Rate This
  • Comments 56

Users have asked why space is required on the system drive (typically the C: drive) when they choose to install Visual Studio 11 to another drive.

While Visual Studio 11 does allow you to install the majority of features to another drive, VS11 still requires space on the system drive for the following reasons:

  • Shared runtimes like the .NET Framework and Visual C/C++ which require installing into the system drive.
  • Packages shared with other products that have their own installation folders like SQL Server and Windows SDK
  • Components shared with other applications like Office or services like IIS
  • Windows Installer and package caches

For Visual Studio 11 Ultimate Beta, about 45% of the entire installation is located on the other drive. We are working to improve that experience but significant drive space will still be required on the system drive for those reasons above.

If you have significant disk space available, I recommend you do not create "system partitions". The system drive is often used for temporary system files, caches of various sorts, and is the default location of %ProgramFiles% unless modified at initial install time using unattend files.

You might instead consider having a partition for the system and applications, and a separate partition for data (documents, source code, builds, etc.). This makes rebuilding a machine easier since, at most, you’d only need to reformat and reinstall one partition (for a domain-joined machine).

If your disk is not large enough or you already have a smaller system partition, there are some other techniques you can explore like mounting another volume as an empty folder, though this may not be supported for folders under %SystemRoot%, %ProgramFiles%, or even certain folders under %ProgramFiles%.

Leave a Comment
  • Please add 5 and 7 and type the answer here:
  • Post
  • (You might wanna join this with my preceding comment.)

    One thing, regarding all of you guys with the SSD problem. Uhm, you figured out in late 2012 to 2013, that a 20GB SSD doesn't suffice for an Windows 7 installation - well, duh!

    Secondly: Is this your first Microsoft Software package you install? Office, VS, all of them; all of them use GBs of space on the system drive.

    Sorry to say that, but you there have a well earned piece of (computer) experience! If you buy less than 60 GB for a SDD you want to install Windows 7 onto, you have noone to blame, but yourself. ;)

  • @rbeer, those backups and fail safes are based on data collected from thousands of installs over the years and have reduced the error rate significantly. We strive to provide a robust installation with a federated model of setup authoring. We do understand that space is precious and are working with the WiX community on solutions, but without those files when you need them you may not be able to install critical security updates or feature additions you want to use. That has been a very common occurrence in the past without a cache.

  • why the FFFF aren't you just allowing the system path to be relocated?

    Can't believe this totally stupid install on C: crap.

    I got a system with C: using SSD to make it fast.. but it's expensive..  not wasting it on some BS that can easily just be moved to another drive. I have to try to figure out some Windows symlinks or something to force it to go on another drive.

  • @rbeer, your statement does not hold water. I happen to have a 60GB SSD. The problem is that no matter what size you get, it eventually isn't big enough. So the real solution is to allow the skilled user (who might install lots of stuff) to move things like the system folder..  tons of junk in Windows folder too!! like UNINSTALL binaries for apps.. gosh that ate up some 10GIGS on mine! I wiped them out.. and when I need to uninstall something I use one of those apps that just delete registry entries and files.

  • BTW, the install screen they made does not work through RDP from Windows 7 apparently!!! I had to walk over to my PC. WTF?  (VS 12.0 (2013))

    However, what DID work out..  OK.. which is the only thing I could do because of all this Microsoft BS... is to set my C: to be compressed. It's an SSD so it's fast.. and compressing it did not slow it down noticeably. I had about 10Gigs free before install, and it went up to 20Gigs after compressing.

  • @a user, we actually test the installer over RDP a lot. If it works locally (meaning you do have sufficient DirectX drivers), are you using the maximum resolution when connecting through RDP to your machine? That could be the issue.

  • My 2 cents:  this stinks.  Come on M$.  Enough excuses.  Have you fixed it in 2012?

  • I tried MANY options in RDP and resolutions including highest and 16bit. It does not work when RDP into my Windows 7. But it does work fine when I RDP into a Win2008R2 instance.

    Either way, it is totally stupid with the graphical BS and even requiring me to use HIGHEST resolution on RDP when maybe I prefer to have a FASTER response rather than PRETTY COLORS is just Microsoft typical.

    Yeah, I'm pissed because I live with this garbage all the time and it's totally because of someone making some decision like "this will look cool!"

  • Simply put: I will find something else to use because of this.

  • Hello friendly commenters,

    I agree this is strange and antagonizing.  Perhaps SymLink can save us.  I'm trying this, will let you know


  • "It's required because we require it, so there."

    A fine answer, Microsoft.  

  • i linked haff my appdata and some of my programs using a folder junction  and it works fine

  • This is like...


    You must be kidding me.

    I got this problem with Visual Studio 2013, the post is from 7 Mar 2012.

    Just wow.

    Like every other ever so big software there in the world can be installed everywhere.

    MS Production? Nooooo, they have their own way.

    If I had a choice, I'd avoid Visual Studio at all costs.

  • tell me which of your product takes less space. How about keep adding junk over and over every time a new version come out

  • With each new version of a major version release (ex: VS2013 pre-releases to VS2013 RTM, and each subsequent VSUpdate) the older files no longer in use are removed from the cache. But each major release shares little in common with past releases so content size is increased if you keep both versions. But since VS2012 and newer does a good job of maintaining backward compatibility with projects so that others with older versions can still open them, I'd be curious to understand why you keep multiple newer versions installed simultaneously.

    Also, the cache solves more problems given our customer data and feedback, as you can read about in many articles from: social.msdn.microsoft.com/.../en-US

Page 2 of 4 (56 items) 1234