The official source of product insight from the Visual Studio Engineering Team
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.
"Many of you have already told us you like our new user interface (thank you!)."
Yes, I for one like the new UI. It helps remind me that programming is about endurance and pain. I'm getting used to the headaches brought on by the lack of color in the Solution Explorer, and when I occasionally switch back to VS 2010, it allows me to have a burst of nostalgia; reminding me of the good old days. Well done Microsoft, you are listening.
I think MS should prepare good deinstalator for VS 2012.
I'd also like to see options to not install VB, C++, SQL Server and TeamExplorer.
As well as all SQL server related stuff.
@PleaseFixYourBugs - It's very sad, but nowadays it has become the norm for companies/people to just flat out lie. I guess they've become numb and it doesn't bother them. I grew up in a different era.
The new interface is very nice except for one thing: the option pages slide sometime left and sometime right. It's a bit confusing...
"Many of you have already told us you like our new user interface (thank you!). "
I do like the new UI. No BS, no sarcasm: I like it.
I personally didn't care much for the VS2010 colors when I looked at the RC for that, but an interesting thing happened: the colors of the UI didn't hamper my productivity in any way once I started using it. Eventually, I stopped noticing the differences in color between that and the previous version.
The more I use the VS2012 RC, the less different it seems; I even ignore the all caps menu like I ignored the other one until I need anything in any of them.
Quit whining about things that don't really matter. Your intransigence marks you as an anachronism.
Thank you for all the comments. I will try to address all of the comments so far.
Let me start by clarifying that when I was talking about our new Setup UI. It appears most comments are about the UI of the IDE and not about the Setup. I apologize for the confusion. Please let me know what you think of the new Setup UI.
For this release, we do not have the ability to choose programming languages. As Visual Studio has grown over the releases, it’s become clear we need to give the ability to choose things like what platforms you are using, like Office, Web, and others. When we brought customization back for RC, we looked into providing language options as well. Providing selections across two vectors, platform and languages complicates the UI and also the engineering. As a result, we were unable to provide meaningful language options except for the Microsoft Foundation Classes for VC++, which provides a significant install savings. We know we have work to do to make customization more valuable which is why we are asking you to tell us what you’d like to see customizable and how you’d use it.
You will not be able to choose not to install LocalDb because several features in Visual Studio now have dependencies on LocalDb. The good news is that LocalDb takes much less time and disk space to install, and is much less impactful to your system than SQL Express was. As for other SQL components, we are currently investigating if we can make a meaningful set of them selectable for RTM.
When designing customization, we didn’t want you to need to know that some Web features use some SQL components, and that LightSwitch uses Silverlight. So, when you have an item selected, it includes all the dependencies needed for that feature to function. For example, if you unselect Silverlight, and select LightSwitch, the Silverlight packages LightSwitch needs to run are installed, and the other Silverlight packages are not.
The things that show up in Add/Remove features are packages that if we were to remove when uninstalling Visual Studio could break other tools or applications, something we want to avoid. That has still left us with more items than I’d like to see. We know we haven’t yet nailed this area.
A consequence of all these potentially shared packages is that doing a full uninstall of Visual Studio takes a lot of steps. We are currently investigating ways we can make that easier at the RTM timeframe. We’d like to provide an option to force remove everything, unless we know there is another Visual Studio product installed that depends on that package.
We have made upgrading from Beta to RC much easier. You don’t need to fully remove the Beta before installing RC, as long as you are staying with the same edition, such as upgrading from Professional Beta to Professional RC. For best results, there are a few packages that do need to be manually uninstalled due to bugs: see the Readme for details (go.microsoft.com/fwlink ). Then, simply install the RC and all packages will be upgraded in place. This takes longer than an install on a clean machine because it is uninstalling Beta at the same time. Due to some efficiencies we can do, upgrading will take less time than uninstalling Beta manually, then installing RC, and is less steps. We expect that you’ll also be able to upgrade from RC to RTM, and some of the performance work we’ve done will make that even faster.
I hope that helps clarify and explain a few things. If I missed something, just let me know. We really appreciate the comments and feedback.
Thanks for the improvements. I know I would love to see the uninstall experience be improved -- especially managing all the dependencies. Earlier this year I went through an experience of trying to uninstall SQL Server 2008, uninstall some pre-release version of SQL Server 2012 (don't remember which exactly), install SQL Server 2012, and install VS 2012 beta, all while keeping VS2010 SP1 working. In an attempt to cleanly remove SQL Server 2008 and the prerelease of SQL Server 2012, Visual Studio 2010 no longer ran. By the end of this whole process, my system was so hosed I ended up having to reinstall Windows from scratch.
I think the whole way that shared components are managed -- not just for VS, but other related products as well, needs to be vastly improved. When you uninstall a product, everything that CAN be uninstalled should be uninstalled, and when the last product using a shared component is uninstalled, the shared component itself should also be uninstalled. It does sound like you understand this need and are already looking for ways to make this happen.
Related...when something is uninstalled, it should be FULLY uninstalled: no dangling registry keys, files or empty directories, cached stuff in the user profile, etc. If this is too difficult to do, maybe the installation is being spewed across too many different places? :-)
Thanks for the discussion.
My personal opinion on the Setup GUI is that it doesn't need to be custom; that makes it look completely out of place. Among the various windows I have open at a time, this particular window is the only one that stands out as being strange. It doesn't have borders, it doesn't have a regular title bar; the buttons don't have a standard look. I would prefer a normal GUI, like those found in every other installers out there, than this special one.
This GUI disregards consistency. It also disregards my choices of a Windows theme & customizations. It feels arrogant: it thinks it knows better than me. There is a reason I have chosen a specific Windows theme; I want the Setup GUI to respect it, like any other app.
However, please don't waste more of your resources tweaking this GUI once again. The sins have already been committed; unless you are switching back to a regular, respectful, consistent Setup GUI, please focus on other parts of the setup experience. As far as I'm concerned, it was quite enjoyable. All I would like to see are more details during the download&install process.
On second thought, my comments about the Setup GUI apply equally well to the IDE GUI...
Thanks David for taking the time to clarify the confusion. However, I'm not buying the statement that it was too complicated to add the language options to the screen. I really don't mean this ugly, but do you realize how silly that is??? Dude, I don't think I'd be telling a dev community that it's too complicated to put options on a screen, when you've had them since the beginning of VS.Net.
Of all the setup options I customise, it's the languages, so it's very disappointing that this feature is no longer available. I always untick VB.NET as it just feels unclean installing Visual Studio with it included.
Regarding the setup UI, I much preferred the previous version that complied with the Windows theme. As with the IDE changes, it's such a waste of time and effort skinning your UI, or trying to force Metro design principles into a Windows app. It's super frustrating that developer time has been squandered on these types of changes that practically nobody has requested or wants, especially when there are far higher priority areas needing work.
If the UI hadn't been messed with, couldn't the time have been spent returning the some of the features that we've lost (e.g. the language options)?
Why do I need to install F#? I don't even know what it is!
I find the options a bit useless. I don't mind getting F# or any other .NET language installed but C++ support is huge when not needed at all. And respectively, I can imagine native only developers are not very happy with all the managed languages getting installed. Also installing x64 or ia64 stuff on 32-bit computers does not make any sense.
Why the tools cannot be turned off? For example, why I am forced to install commercial 3rd party Dotfocusator with a licensing I even might not agree with?
For me, the major thing lacking from the installer was information on how to make an informed decision on what items could be safe to choose not to install. What exactly is included in each option. I spent more than the 8 minutes you saved on the installation process searching for this information on the web (to no avail). Most options except the MFC option did not save a significant amount of hard disk space, so realistically were useless toggles (aside from perhaps security / servicing concerns).
FWIW VS2012 installed in well under 10 minutes on my SSD.
Those Intel Cherryvilles are pretty serious.