Make the installation of Visual Studio light-weight and fast
Installing Visual Studio takes too long
There's a lot of stuff that the VS installer installs that I probably never is going to use.
Make modules and packages install when needed. The Office-install has had this option for ages, where you can deceide whether you want to install a feature a) now, b) when needed, or c) never. That way the basic install will probably be a lot faster and it will take up less space on our drives (how many terabytes of never-used-features do you think VS is accumulating worldwide?).
I belive you already have the package system to handle this (nuget), so eat some of your own dogfood and show us that the package system can handle app installs as well :)
We’re delighted to say that Visual Studio 2017 is now released, including a completely revamped installer in response to this and other feedback. The smallest installation of Visual Studio is one-tenth the size of previous versions and takes on average just three minutes to install. Build-to-build upgrades take just a minute or two. You can select a workload of your choice – we won’t install things that you’re not going to use.
To the proposal, we support in-product acquisition of components on demand. You can just hit Ctrl+Q (quick launch), type the feature you want, and we’ll take you straight into an installation experience for that feature.
Thanks for the great feature request – we hope you like Visual Studio 2017! Download it from http://visualstudio.com.
Barry Carr commented
A light weight mode for Visual Studio that is code focused. In this mode all installed languages would be recognised by the editor, including mark-up languages like HTML, CSS and XAML, etc. The IDE would still provide intellisense and refactoring tools/addins should still be able to function. However, in "lite mode" no visual designers would be available, nor would they be loaded into memory.
I suggest you to make VS and empty IDE which I can download languages in it instead of making many softwares (EG: VB, VC#) which the size of each on 250/300 MB and it is almost the same and the difference between it is the language which I'll use in each software.
I would love to see something like this - the possibilities are endless
Jeffrey Fritz commented
Highly agree... I would really like to unload from VS features I don't use like the data manager, server manager, and UI designers
VS could solve this the same way winsxs does, actually - by using hardlinks (which is why winsxs appears so much larger than it actually is). When setting up a project, VS would just hardlink/symlink in the files from a central location on disk.
Checking the linked files directly in to source control would break that, but checking in a recipe and having VS (or the CI server, or whatever) automatically make sure the recipe is up to date when opening the project would be one solution. Or, maybe better, have the dependencies just be in the project file.
The big issue I see is that this would probably mean refactoring most of Visual Studio, so it's pretty unlikely for v.Next - maybe v.Next.Next.Next :)
Rudi Larno commented
@David Nelson: This is a mere suggestion, sure there are more issues to be solved. But for me (and I recognize I'm probably alone) I currently have a base VHD (Win7 SP1 + VS 2010 SP1) with several differencing VHD's, where each diff vhd contains extra VS CTP, or add-on installs (Silverlight, WP7, Azure, whatnot) that are needed for projects. This allows me to easily switch between projects, not having to worry about if things will break. But at the moment this takes a heavy toll on disk space +/- 5-10 GB pre diff vhd.
So even having all of the files required per project would still be better than what I have now. Yet as Mark states, there is no reason why a package manager could not solve this. E.g. reference a certain file/version and only load it when needed. So one could have all versions side-by-side on disk, and only based on the current solution would you reference/load the required files.
Btw: if you are running Windows in x64 bit; take a note of the size of the Windows\winsxs folder.- MS is not concerned about your disks.
Mark Rendle commented
This request echoes the thoughts I expressed in this blog post: http://blog.markrendle.net/2011/06/28/how-i-would-like-microsoft-to-distribute-net-v-next/
As I said then, I think distributing the higher-level frameworks (WPF/WCF/WF/EF/etc.) through NuGet has obvious advantages. To answer David Nelson's comment, there is no reason why a package distribution system can't be made to work at a higher level, as for example RubyGems does, where "gem install" applies the gem to your whole system, and bundler and Gemfiles can be used for specific projects. The issue is not with this idea, but with the implementation of the package manager, which is rapidly evolving (and, btw, is the best thing to happen in .NET since LINQ).
Chris Fannin commented
Superb suggestion! 3 votes for this. I also don't use a large number of the built-in features and instead rely on an add-in.
I'd like to be able to disable and enable features on-demand like I do with Visual Studio 6 add-ins (yes, I deal with legacy code). That dialog even let me control if an add-in is loaded at Startup or only active for the current instance.
The "optional" (non-core/critical) VS features could be listed in the Add-in Manager under a separate section to indicate they are provided components. On first install of VS, either provide a dialog to set the initial state of each component like the Windows Features one, or default them all to Enabled as they are now. (Sidenote: I agree with Colin on merging Add-in and Extension Manager.)
To help pinpoint those features/components that are "unused", the new dialog/section could include a "Last Used" date beside each entry, similar to Add/Remove Programs in Windows but more accurate.
David Nelson commented
Would you really want all of the files necessary to get, for example, all of the IDE functionality related to a Silverlight project to be duplicated in every Silverlight project you have?
What we need is a more modular IDE, where people who don't use certain project types don't have to install the related tools. But I don't want to have to keep a separate copy of the WPF designer and XAML compiler in every single WPF project I create.
Mark Heath commented
Nice idea. Another benefit would be that VS extensions such as templates, code snippets and custom commands could be active only when working with certain solutions, rather than being present all the time.
Marcos Fábio Jardini commented
Agree, VS need be more modularized. As I suggested in Channel 9 :: Going Deep:
* Back of Standart Edition: Come clean and accept 3rd party plugins
* VS as an IDE + visual Debug, using MSBuild for build/project, WinSDK compiler (no more crashes like the WSDK 7.1 SP1 and embedded WinSDK from VS)
I don't use any of the VS refactoring tools - I have ReSharper for this, so its a really pain to have all the VS refactorings also available in the menus.
Colin Bowern commented
Part of this can come from introducing more consistency into the IDE. Every product group is trying to get their stuff noticed by creating their own menu options and project types. Examples:
- Add-in Manager should be merged with Extension Manager
- Azure should be a deployment target, not a special project type.
- Attach to Process should be in the Debug menu
- Choose Toolbox Items should be under Customize
- Architecture should just be another item type, not a menu
- WCF Service Configuration Editor should just be a project properties tab
- Installer should allow me to pick my combination of language and targets (i.e. web, windows, services, etc...) so I can only install the bits I care about - then you can make intelligent decisions about which help packages and other things to include in the install.
Someone needs to step up and own the overall user experience and work with product groups to find relatively consistent ways to behave within the UI. That will reduce the clutter and crap and ultimately slim down VS both from a size UX perspective.
This is especially true for C++ developers. Managed languages share a huge amount of common code. C++ doesn't, but its IDE is still bogged down by those hundreds of packages. VS is just growing too big for a single monolithic application.
Rudi Larno commented
Visual Studio could be a lightweight shell with only the basic project templates installed. Whenever you then need to add new template such as Windows Phone, Silverlight, Azure, ... you could create an empty project and use NuGet to install all the extra files and UI to get it to work. And as is the case with NuGet, this install is relative to the solution/project that you are using. NuGet all of these artifacts from an official package server, and link it locally to the solution.
This would be benificial for us 'consultancy' folk to keep VS to a minimal install and only see all the extra file templates, context menu-options, etc. based on the solution you are actually working on.
A second benifit would be to be able to check-in all the required VS artifacts into Source Control so that when a new developer starts on the project, they install the basics, and then 'Get' the solution from Source Control and they could be up and running.
A third benefit would be that the Team Build Agents would not all need a full install of VS Ultimate just to be able to build some types of solutions (.targets files and dll's in the GAC missing). Again, doing a Get from Source Control should place all required files in the build folder and Team Build should be able to pick everything up from there.
A fourth benefit is that as new versions of frameworks (Asp.net Mvc, Silverlight, Azure) become available, it should be much easier to update the solutions, the NuGet package could do its work to upgrade the project.
A closely related fifth benefit is the acutal opposite. Suppose we have build a project with Asp.net Mvc 3 and today (they are going fast) we already have Asp.Net Mvc 5 on a new project we are working on. Now we need to do some maintenance, or new work for the Mvc 3 project. When we open up the Mvc 3 solution, our IDE still only knows about and behaves like it used to. We can still code and debug like we used to, there is no interference.
Martin MacPherson commented
I don't use a lot of the features that VS provides and I imagine that a lot of people are in the same boat. eg..MSTest, all items on Analyze menu item, all items on Architecture menu item, items on Data menu item, toolbox. I reckon that if VS could be modularised even more so that users can stop having to install everything then it would hopefully improve performance and stop it feeling like a monolithic beast. I know that some work has been done on this front but I feel that you need to be way more extreme/critical.
To highlight what I mean, SharpDevelop comes in a 15meg installer, compared to 2gb iso for VS. SharpDevelop provides all the IDE features that I require. It is only the lack of support for a couple of project types and Resharper support that stop me using it full-time. It certainly out performs VS in my opinion