I am doing work for a company that is wanting to put all their .Net applications (web applications, Windows applications and console applications) together in a single Visual Studio solution.

I am looking for experience from developers who either structure their own applications this way or who work in a company that does this. Is this a good idea?

  • What are the pro's/con's to putting all your applications in a single solution rather than having separate solutions for each application?

  • How fast is Visual Studio with a solution of 20+ projects?

  • And how stable is the solution file with source-controlled concurrent development?

closed as too broad by Martijn Pieters, gnat, user40980, Kilian Foth, Dan Pichelman Mar 3 '15 at 15:32

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Keep in mind that answers might be specific to particular versions of Visual Studio. – stakx Jun 20 '14 at 7:46

Recently, we migrated nearly all the source code in my company into a single solution.


Originally, we had dozens of solutions. Some projects from a solution reused projects from another one, and nobody cared about using a package manager. The day you substantially change a project which is used nearly everywhere, expect hours and hours of lost work for the entire company for the next days or weeks. The worst part is that you can't even know what exactly would be affected by the change.

Merging all the code into one solution was an alternative. It works well for the moment, and the dependencies are now easy to follow. Want to modify a method but also track the repercussions this change may have anywhere in the code base? Visual Studio can do that with ease. For me, it's a success.

Continuous integration is now easier too. One solution to compile and to deploy. Nearly nothing to configure.

Is it scalable?

Performance-wise, I was very surprised by Visual Studio. I thought that it will start crying with a solution with, say, 50 projects. Today, there are more than 200 projects; Visual Studio appeared to be scalable enough to manage them as if there were only 20 of them. Yes, there are things which take time. If you recompile every project, with Code contracts, Code analysis enabled by default, etc., expect it to take a while. But nobody would expect to compile 200 projects as fast as 10, and by the way, you shouldn't: this is the role of the Continuous integration server. Startup time (cold start, then loading the solution) is impressively fast; maybe not as fast as with 10 projects, but still very acceptable (under 20 seconds on a machine bought more than five years ago).

To go even further, systematically unloading projects is a good idea (and really easy when projects are organized in directories within the solution). If somebody works on something which requires only three projects to be loaded, there is no need to load all the 200 projects (unless, of course, dependencies may be affected).

Version control works as expected as well (I'm using an SVN server, if it matters). I haven't worked in a real concurrent environment, with, say, dozens of developers frequently committing code, but I would imagine that this wouldn't have too many issues. Just beware of the cases where many developers add new projects at the same time: merging the .sln file is not the easiest thing to do.


If I had to pick the decision again:

  1. I would still migrate everything into a single solution. This reduces enormously the pain of broken dependencies, and this benefit alone is totally worth it. Having a centralized place for all the code is also a good idea; this makes it possible, for example, to search for something within Visual Studio. I can also work on two weakly-related projects, and still have just one Visual Studio window opened.

  2. I would also study a bit more NuGet and the ability to host a private NuGet server. Managing the dependencies through NuGet can solve some of the problems when you don't want to merge a few projects into the common solution. Personally, I didn't have such cases, but I imagine that other companies might have.

  3. Finally, investing in an SSD for every developer can make a huge difference. But you don't need to, and in my case, the code base is still stored on an ordinary hard drive.

  • 2
    Just some points FYI: You can also open projects via the .csproj file in VS if speed/performance is an issue. A NuGet "private server" is just a network folder (and add that folder as a package source location in VS) - just drop the nupkg files there and it works. – Steven Evers Sep 27 '13 at 22:16
  • Thanks, MainMa for sharing your experiences with a single solution setup; a very detailed and helpful answer. A reservation that I have is with having all the applications together in one solution is having to give a junior developer access to everything. We use Ankhsvn and I would rather give a junior developer the URL for a single application that I want them to work on than give them access to everything. Any thoughts on this? – BruceHill Oct 1 '13 at 8:22
  • @BruceHill: with SVN, you can configure precisely who have access to what. The junior developer will still be able to see every root directory (see my question on Server Fault), but won't be able to access restricted projects. – Arseni Mourzenko Oct 1 '13 at 9:13
  • 2
    Working for a few large companies with large teams of developers committing code daily I can tell you that the single solution approach does not work. Each project is overhead. Loading up, building and god knows what pre/post build steps someone might have attached to said projects. Now with a large team of developers, you will have changes across many of those projects each day. Include running unit tests, etc with each check-in for continuous integration and then you have even more overhead. Have a single solution per deploy-able unit (service, website) and use a package manager like NuGet. – Always Learning Aug 22 '15 at 4:54

This is the intended usage.

What are the pro's/con's to putting all your applications in a single solution rather than having separate solutions for each application?

  • pros:
    • easer references between projects
    • easier debugging/stepping through
    • easier to attach to processes (ie. you're stepping through a windows service, when it jumps to shared library code, and it just works because all of the symbols are already loaded and accounted for)
    • code search within the ide works better (you don't necessarily have to know which project the code you're looking for resides in)
    • cross-project changelists are easier to manage (ie. you changed library code, so you have to update client code at the same time, with 1 checkin)
  • cons:
    • build speed: if you're in the habit of "rebuild all" then builds take longer. Much longer, and incremental builds sometimes have funky behaviour.
    • ide speed: see next

How fast is Visual Studio with a solution of 20+ projects?

With 20+ projects... might not be so bad. I've seen more without VS having problems. It's pretty stable/quick. HOWEVER... if it is a problem, it can be mitigated: open the .csproj in VS and work from there. You don't get the benefits of having everything in one solution, but you can always re-open the sln when you need to and work in just the .csproj when you need to (like you do now).

And how stable is the solution file with source-controlled concurrent development?

The solution file only changes when you add/remove projects or solution-level objects, so it rarely changes. It's xml, so you can see what's in it. They change rarely.

  • Steve, you said "This is the intended usage." Can you provide a reference for this? Thanks! – reformed Mar 13 '17 at 20:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.