Use Nuget to install most of the components
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.
Rudi Larno
shared this idea
13 comments
-
Rudi Larno
commented
@smashing-your-customers. I agree they are going the wrong way, and (imho) are loosing a lot of credit with their developer community. They could (and can) build great products/frameworks and let the 'absolute awesomeness' of their products/frameworks sell themselves. The forced MS-Marketing-Push-It-Down-Our-Throats approach of old (regarding Metro/Windows) is in stark contrast to the way the Scott's (Guthrie and Hanselman) are providing an effective, popular and open web-platform.
-
smashing-your-customers
commented
The only problem I see with this is, how would MS push people to develop for whatever "hot new thing" they're pushing? When Silverlight was all the rage, they knew they had you because tools/support could not be removed during a VS install. Now they're pushing Metro/WinRT apps, and the install options are even less than 2010.
-
Rudi Larno
commented
-
Rudi Larno
commented
-
Hossein Aarabi
commented
I belive this is planned by MS, according to MS comment on a similar request.
No edit functionality? hmmm
-
Hossein Aarabi
commented
I belive this planned by MS, according to MS comment on a similar request.
-
Dennis
commented
This is essentially what they are doing with ASP.NET MVC4 Beta. Now they just need to stay on that path and do the same thing with all the other project types.
-
Glenn
commented
I would love to see something like this - the possibilities are endless
-
jdhardy
commented
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).
-
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.
