How to change Visual Studio 2012 install directory?
What do I have to destroy to change the install directory?
Answer: You can change the physical directory without the need to "destroy or change" the install directory. This is an alternative "think smarter not harder" solution proposal.
Here are the specific material details you need to continue to use your logical M:\Program Files directory and solve the physical where the files are stored problem.
It also serves the rest of the community well for cleaner more reproducible installs, less effort and risk when using Beta builds. Its less risk because it encapsulates every file in the beta install. Want to go from beta to RC, no problem, just don't mount the beta drives, use an off the shell registry cleaner and reinstall clean to fresh drives every time.
The process uses PGP disks which can be logged in and logged out of / backed up as needed.
Initially, it seemed as though it would be possible to create just two drives. not so.
- Drive #1 mounted as F:\ for f:\Program Files (x86)\Microsoft Visual Studio 11.0
This is where I told Visual Studio setup to install files to. And it does function as a mountable container for 2.7 Gigs of files.
- Drive #2 mounted as a folder on "C:\Program Files (x86)\" "Microsoft Visual Studio 11.0"
The intended purpose of the mounted folder was to collect up the remainder of 5.5 Gigs of files.
The actual list of 33 created folders I had to move to additional PGP folders.
Here is the inclusive list of folders you can create before setup deploys files to them.
C:\Program Files\Microsoft SQL Server
C:\Program Files\Microsoft SQL Server Compact Edition
C:\Program Files\Application Verifier
C:\Program Files\MSBuild
C:\Program Files\Microsoft
C:\Program Files\IIS Express
C:\Program Files\IIS
C:\Program Files\Microsoft Visual Studio 11.0
C:\Program Files (x86)\IIS
C:\Program Files (x86)\IIS Express
C:\Program Files (x86)\Microsoft ASP.NET
C:\Program Files (x86)\Microsoft Help Viewer
C:\Program Files (x86)\Microsoft SDKs
C:\Program Files (x86)\Microsoft SQL Server
C:\Program Files (x86)\Microsoft SQL Server Compact Edition
C:\Program Files (x86)\Microsoft WCF Data Services
C:\Program Files (x86)\Microsoft Web Tools
C:\Program Files (x86)\MSBuild
C:\Program Files (x86)\NuGet
C:\Program Files (x86)\Windows Kits
C:\Program Files (x86)\Common Files\Merge Modules
C:\Program Files (x86)\Common Files\Microsoft
C:\Program Files (x86)\Common Files\microsoft shared\DevServer
C:\Program Files (x86)\Common Files\microsoft shared\MSDesigners8
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv
C:\Program Files (x86)\Common Files\microsoft shared\MSI Tools
C:\Program Files (x86)\Common Files\microsoft shared\SQL Debugging
C:\Program Files (x86)\Common Files\microsoft shared\SQL Server Developer Tools
C:\Program Files (x86)\Common Files\microsoft shared\TextTemplating
C:\Program Files (x86)\Common Files\microsoft shared\Visual Database Tools
C:\Program Files (x86)\Common Files\microsoft shared\VS7Debug
C:\Program Files (x86)\Common Files\microsoft shared\WF
C:\Program Files (x86)\Common Files\microsoft shared\Windows Simulator
This is perfect to prevent;
- Patch managers and patch management systems which inadvertently & unsupervised unmonitored, unaudited in willful ignorant bliss violate the premise of good promotion to production change control best practices
Could have used True Crypt or PGP desktop. Just not whole disk encryption, have to be able to mount and unmount the resources.
I appreciate the hard junction approach, but unless you Safely ejecting & power off drives, it offers little process compliance and is neither safe or reliable as compared to safe PGP un-mounting/mounting. Developers will just power on the drives and make changes.
Regarding level of efforts to backup and restore, Backing up PGP drives as compared to hard junctioned drives is a wash about the same level of effort. But the value in not having to remember which folders are junctioned, which might need restored to restore a dev environment favors the fewer number of .PGD drives which contain all the needed folders ( ie do the remembering for you as a part of their function)
Consider this as an environment for when requirements are for mandatory non discretionary absolute auditable surety for a reproducible secure build. To meet that core objective, it has to be available only when its actually "needed" and has to be secured when its not needed.