About Windows Installer, the .NET Framework, and Visual Studio.
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:
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%.
"package caches" for Windows Installer should never be on the system drive. Sloppy design.
@W.R. Isaacs, which drive would you suggest? Drives - even SSDs - are sufficient these days and "system partitions" should be avoided. Program Files, for example, can only be set to a different location during an unattended Windows install so in most users' case, things will install to the system drive by default.
I got a brand-new all-in-one machine with just 20GB of SSD disk. So "SSD" are not always sufficient.
If you take near to 17 GB of Windows 8 installation, it let you only 3 GB for all the programs like Visual Studio 2012 that really need to install stuff on it.
So now I find I cannot install VS because I don't have enough space on C:
It's definitively annoying...
I have a 60 GB SSD with just windows 7 on it and Visual Studio 2010 takes up so much space that I only have 7 GB free. I have two separate Terrabyte hard drives I would love to install Visual Studio 2012 to but it needs 5GB from the main drive which would leave me with just 2 GB free. Updates probably wouldn't be able to install because there isn't enough room.
I'm exactly in the same situation as @Javier with 20GB ssd with 1gb free space when VS requires 1,5gb. Now will I never be able to install VS or what?
*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
I'm not the smartest guy around to argue about some piece of software, but this is utterly annoying. Do you have "shared" stuff in every goddamn program? I'm in the exact SSD situation as everybody posting around here. Machines have shared data stored on SERVERS, for Christ's sakes! You can't make a program use shared information from the same computer? It's lame and this is annoying a lot of people, not just me. If this is today's Microsoft, you should be ashamed of yourselves! Each of your idiotic proprietary programs needs the system drive and they all occupy 10 times as they normally should. Did neither of you hear about 20 kb drivers and simple looking interfaces? Everybody is beating their heads against a brick wall just to come up with more demanding applications, as the hardware permits it. If it doesn't, well... The retarded consumer should go for a new one: bigger hard drive, faster processor, top-notch graphics card. You are part of this consumer-oriented market that doesn't care about the aforementioned component. One day you'll regret this stupidity. Buttons should be rectangles and the mouse arrow should not have a shadow. *** should just run.
@Tudor, shared packages are shared and installed to a single location on the drive, but the source cache is there to repair the product. We get a lot more user feedback when users have to go searching for media when repairing their product (missing files have to come from somewhere). The content of this post was that a number of things only support getting installed to the system drive for one reason or another.
Why do you keep mentioning "system partitions"? I think most people have a similar setup of a smaller SSD for OS and a larger HD for apps i.e. different physical disks not partitions.
When a 'recommendation' includes instructions related to drive partitioning options, then you may want to rethink your product, its footprint, and its so-called requirements. This one is a critcal one in that we rarely have control in a corporate world over partitioning schemes nor do we have control over critical, critcal operating system drive space. They never give us enough and this encroachment is about as bad as I've ever seen in 40 years. You used to have it right -- at least for us -- but using the registry to "point to the locations" for the installed product and leave a shell of folders on C:
Please rethink this one. It precludes the installation on a lot of VM's where we prototype products where the drives are only 30-4Gb images. WinSXS + VS + Windows and we are out of space. Talk about bloat. C'Mon Man!
- Roger / Boeing Seattle.
@Roger Jerrell, I appreciate the predicament and there are ways to move the Burn cache (Burn is the setup engine we use for VS, but is used for many other Microsoft and non-Microsoft products as well). I am working on a post to address that.
But, caching the payload was a conscious decision deliberated over several years. We have lots of error data because of missing source packages - things Windows Installer does not cache (and because of our full cache, we've made changes to reduce the size of the Windows Installer cache). It's probably no consolation, but the failure rates for repairs, servicing, and even uninstall have drastically reduced. You're not prompted for media anymore, and this could be problematic in servicing events because your installation media may not have been what was required if the package being prompted was updated.
I can tell you that Burn does cache to the %ALLUSERSPROFILE% / CSIDL_COMMON_APPDATA / FOLDERID_ProgramData folder. Administrators during deployment of Windows can customize that folder to place it on larger partitions or HDDs if in an SSD/HDD combo environment.
I feel like buying a SSD for my OS was a waste of time and money. I had to install Microsoft Office on another computer because it wouldn't fit on my SSD, because it seems most Microsoft programs only want to install to the Local Drive. Which is very aggravating, because now I cant do anything on this computer unless I buy a bigger SSD or another HDD and re-install Windows for the second time, which defeats the purpose of having a SSD in the first place. If anyone finds a solution to this, please let us all know.
Strongly agree with the rest of your critics, particularly since Microsoft is also not providing a supported way for us to install our Windows Store apps in another location as well. Between Office, Windows Store Apps, SQL Server and Visual Studio, I'm finding that I'm having to carefully manage my system SSD of 120GB, which does not seem acceptable to me, as I have a 2TB drive available for non-system file storage purposes. Is Microsoft planning on dropping supporting additional drives completely, then? Their software installations seem geared that way.
@James, Microsoft in general does support different drives but for one reason or another (for example, because of default ACLs defined for certain directories) well known folders are used for different data. Program files go into %ProgramFiles% and their data often in %ProgramData% (using per-machine or per-user locations).
If you really want to control where things go, I suggest defining these with an unattend.xml file since some of them (like %ProgramFiles% / %PRogramFiles(x86)% can only be defined initially when setting up windows. I can add specific instructions to my backlog of blog posts to write.
This is freaking joke. I use machines with 30-60GiB SSD as system drive. I am developer. I use superbloated software from ibm, oracle, etc. Any problems with installing them on other drives? Not even once. Fix it MS. I paid a lot for VS12 license and I can't even install it.
First of all, my respect to you Mr. Heath Stewart, how calmly and factually you reply to those sometimes rather emotional comments.
Basically I have a slightly off-topic demand: Give us more control over the system! Let there be dummies, that shall not temper with an OS - fine with me. But obviously there are others! And here we are, complaining. With every right, I might add.
You implemented hundreds (so it seems) of little fail safes; backups here, restore points there and so on.
We don't need that, you know? I'd suggest putting more work into error handling and LOGGING those errors. At least for "Professional" and beyond.
That is, by the way, what real IT enthusiasts and professionals make chose Linux over Windows! It might seem pretty cluttured, but once figured out how all of that works, it is just a blessing!
Error -> open logfile -> find errormessage (e.g. missing file) -> creaty symlink at or copy file to desired location -> done.
Opposed to the windows way of handling errors:
Error -> open eventviewer -> find gibberish -> end up reinstalling whatever caused the error.
That's not the way to treat "Professionals" or "Ultimates", guys! ;)