Setup Improvements for Visual Studio

Setup Improvements for Visual Studio

Rate This
  • Comments 82

Setup is the first experience most of us have of Visual Studio, and in the Visual Studio 2012 we’ve made significant investments in improving your experience. Many of you have already told us you like our new setup user interface (thank you!). We have also been investing in ratcheting up the speed at which we lay bits down, improving the experience for non-English installations, and honing the experience you use to select which components to install.

Let’s start by looking at the last of these first. As many of you noted, the Visual Studio 2012 (11) beta didn’t have the capability to customize installation. Although most users select the default (which is to install the full product), a significant number of you customize the installation. During beta, we hid the customization option to help us gather more data on full installation performance and reliability. We’re happy to say that we brought back customization in Visual Studio 2012 RC. Based on the choices you make, the customization allows you to reduce your install size by about 2.5GB and about 25% of the install time.

During the beta timeframe we ran a survey of several hundred beta users and asked they would like from setup customization. The overwhelming answer was to improve VS performance by not having it load features that aren’t used, followed by reducing the complexity of the product and reducing on-disk size. We think we’ve gone a good way toward addressing these desires, but we know we can do more. We are very interested in how you’d like to see this look in future releases, what level of granularity you’d like, and what kinds of things you want to customize about your Visual Studio install. So please give us feedback on setup customization, either in the comments to this blog post, in the Forums, as suggestions on User Voice, or as bugs you log on Connect.

Customization isn’t the only investment: one of the most significant areas we’ve invested in is the speed at which setup lays bits down. Whether you’re installing Visual Studio Express products or a full installation of Visual Studio Ultimate, we wanted to shorten the amount of time it takes to get you coding. From setup perspective, we look at a couple of measures of performance. The first is how long it actually takes to complete a full installation of the product –about 35 minutes on average for a full installation of VS Ultimate from local media on test hardware representative of the average VS customer. We also look at the throughput we are able to achieve during installation – how long each VS package takes to install relative to its size. As an example, some packages that compress really well but are otherwise very simple like MFC maintain a throughput of up to 7MB/Sec; other packages that are small but need to place files in the global assembly cache or write a lot of registry keys may achieve throughput below 1MB/Sec. From beta to RTM our goal was to improve both of these measures: the amount of time it takes to install VS in absolute terms and overall the throughput.

To do this, we undertook several efforts. To start, at the beginning of the Visual Studio 2012 cycle we transitioned off of our old install engine onto a new engine that by itself is capable of maintaining faster throughput on simple packages than the setup engine we used in VS 2010. We also made a change early on to parallelize the download of the packages we’re installing as the installer is running so that much of the download time happens in the background while installing.

But that wasn’t enough. So we asked ourselves a pretty audacious question: between beta and RC could we cut 10 minutes (about 30%) from the installation?

For the last three months, that’s what we’ve been trying to accomplish. We found places in setup where we were calling the same function repeatedly where we didn’t need to. We unpacked the templates from VSIX packages and put them into MSIs to eliminate the double-decompression. We found several duplicate packages and, although the installation process wouldn’t install them, we removed them to save the seconds it would take to check to see if they were already present. And of course we reduced the number of custom actions.

So did we make our 10 minute goal? Almost: we eliminated a little over 8 minutes off of the installations in our performance lab before we had to begin locking the release down. For the rest of the release we’re going to focus on maintaining those improvements and setting ourselves up for a great RTM.

One more thing for users who install VS in a language other than English: Visual Studio 2012 supports language packs. Language packs make it much faster and easier to add an additional language to Visual Studio because you don’t need to download and install a full version to add a new language: you just add the pack for the language you want. 

Please let us know how we are doing and how you’d like to see setup change in the future. We have a lot of good ideas already, and are always open to new ideas or to confirmation that we are prioritizing ideas correctly. As always, we are reading your comments on this post, watching for issues in the Forums, listening to your suggestions on User Voice, and reviewing any bugs you log on Connect.


David Guyer – Senior Lead Program Manager, Visual Studio Setup Team

Short Bio: David Guyer is currently the Lead Program Manager for Visual Studio Setup and has been working on deployment technologies in Visual Studio since Visual Studio 2002.

Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
  • I have created a new UserVoice suggestion. If everyone posting here feels as I do about installation customization, please take a moment and vote.

  • I really appreciate the ideas and input around customization you all have shared.  The proposed tree structures from @YangHua and @ollydbg are helpful too.

    In one of my first responses, I tried to explain why we don’t have programming languages as selectable items in this release.  There have been a number of follow-ups specifically about that, so I thought I’d revisit it once more.

    If we look into the principles behind customization, we find that the reason people customize varies: lower disk space, faster install time, less clutter in the UI, less stuff to load so VS will run faster, etc…  The theme however consistently boils down to “I don’t want to install something I don’t want to use”.  As we look at the growth of the size of Visual Studio, it is not driven by programming languages; rather it is driven by the addition of new platforms such as Windows 8, ALM features, new Web platforms, and many others.  So the old programming languages model we used up through Visual Studio 2010 is less useful than it used to be.  That’s not to say programming languages isn’t important, they both are.

    For both platforms and languages, there were things that we were unable to make selectable given the short runway we had after the Beta feedback came in.  Several platforms are not selectable, and also VB, C#, and F# are not selectable.  This is primarily due to an increase in dependencies that complicates pulling them out.  Part of that is due to us realizing that we need to provide options across two vectors, platforms and programming languages, and the two are not independent of each other.  For example, if you choose web development, you can do so with VB, C#, JavaScript, or C++.  If you want to do multiple platforms, do you need the dials to say “VB for the Web and C++ for Windows Client Apps” and C# for SharePoint”? Or is it OK to install all of VB, C#, and C++ in this case, and all of Web, Windows Clients, and C#?  It’s an area we will be able to work on starting from the beginning of the next release which should enable better results.

    @Heath,  I really appreciate the new UserVoice item, and actually noticed it a couple days ago before working on this post.  It’s already the 2nd highest item for setup, and I do encourage everyone who feels strongly to vote there.  It does factor into our planning and prioritization.  That item is here:

    I hope this helps to clarify where things are now and explain a bit more the why behind it.  We’re not done, we'll be working hard on improving programming language customization and also expanding the platforms that are selectable, and your feedback is really helpful in pointing us in the right direction and explaining why this is important.

    Thank you,

    David Guyer

    Lead Program Manager – Visual Studio Setup

  • If we are talking about the installerб I have a question, does Visual Studio 2012 RC Professional installs some of the following products too: SQL Server, LocalDB, SQL Server Compact?

    If yes, so how can I connect to SQL Server via VS2012 after finish of VS2012 installation?

    Also, I don't see any hint, related to SQL Server presence on my PC, neither in Services list, nor in All Programs.

    So, I don't know if SQL Server is really installed already and if should I install it separately?


  • Why on Earth do I have to install most of the files to C: drive? Is it some kind of religion or what? My C: drive is SSD and it holds system files and nothing more. Right now I simply can't run VS2012 as it wants 7 Gig of my C: drive when there are more than 512 Gig on D:

    It looks more like a joke when I change installation path and it moes just 2 gigs out of 9.

  • User should select at least one language, otherwise prompt warning and cannot continue to next step. Language means basic features, and XXX development means additional headers and libraries.

  • Why I am not allowed to post comment?

  • It seems to me that if your main goal was to cut down on install time, you could have done that much more effectively by...allowing users to skip installation of languages or tools that they won't use. I know you have said that is "complicated", but then I have to ask, why was maintaining the separation of languages and platforms not a priority during development? Of course if you only tackle it when the installer team starts working near the end of the development cycle, it will be a nightmare. Removing what is obviously considered by your users to be a critical feature, and then touting the "improvements" you have made to the setup process, makes you look out of touch at best and disingenuous at worst.

  • there was a loooot of setup improvements in VS.NET 2005 and in VS.NET 2008 and then in VS.NET 2010 and now in VS.NET 2012, and it is always the same propaganda.

    it will always take 7 hours to install a VS.NET service pack!

  • While you may have cut 8 minutes off for many others I've been trying to get vs2012 for three days now.  

    Perhaps you could lend a hand at:

  • 35 minutes to install?

    im installing it and its taken over an hour already.

  • Not a fan!  The install is way too heavy.  I had to trash my development VM and create a new one because I couldn't find enough room on C for the install (Windows 7 bloat ate my C drive) while I had plenty of space on other partitions...  I already miss the old installer where I could leave off all the languages and other stuff that I do not use (sorry, I don't do a lot of F# or C++).  The color scheme does nothing for me either.... and I know this is irrelevant to this post but I have to say that the new 2012 IDE UI color scheme and icons are HORRIBLE!  I was all set to see the updated SQL Server 2012 IDE when VS2012 lunched, but alas I'm now plagued with a colorless, washed out, grey scale mess of an IDE (and the "Dark" theme is worse).  I for one am not happy about the direction that all this is going.  It reminds me of an old copy of x-windows...  Who asked you change it?

  • This is my second or third time installing VS.NET 2012 Ultimate Trial on differnent Windows. I used the online setup version, and it seemed like it takes hours and it did not give the details but only moving blue dots. I often wondered if it was even working. The old version gave more details like the file names currently being installed.

    My internet connection is 100Mbps so I do not think this is becauses of slow downloading speed. You need to make it faster.

  • I hate 'Install All Junk Stuff to C:\'. Cannot believe Visual Studio will do that!

  • I downloaded the 2012 Pro ISO yesterday and it has now been installing for 18 hours on my win7 x64 Pro i5 3.1GHz with 8GB, doing not much else. We had similar issues in the old days with 2k5sp1 (I think) do you have a fix!

  • The VS2012 installer is a major step BACKWARDS!  It's horrendous, slow and there's simply no execuse to mess with something like customization and language choices that was working perfectly fine in VS2010! The setup team should hang large "If it ain't broke..." banners around their work area...

Page 5 of 6 (82 items) «23456