Best practices for large solutions in Visual Studio (2008)

Question

We have a solution with around 100+ projects, most of them C#. Naturally, it takes a long time to both open and build, so I am looking for best practices for such beasts. Along the lines of questions I am hoping to get answers to, are:

• how do you best handle references between projects
  • should "copy local" be on or off?

• should every project build to its own folder, or should they all build to the same output folder(they are all part of the same application)

• Are solutions' folders a good way of organizing stuff?

I know that splitting the solution up into multiple smaller solutions is an option, but that comes with its own set of refactoring and building headaches, so perhaps we can save that for a separate thread :-)

Solution 1

You might be interested in these two MSBuild articles that I have written.

MSBuild: Best Practices For Creating Reliable Builds, Part 1

MSBuild: Best Practices For Creating Reliable Builds, Part 2

Specificially in Part 2 there is a section Building large source trees that you might want to take a look at.

To briefly answer your questions here though:

• CopyLocal? For sure turn this off
• Build to one or many output folders? Build to one output folder
• Solution folders? This is a matter of taste.

Sayed Ibrahim Hashimi

My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build

Solution 2

+1 for sparing use of solution folders to help organise stuff.

+1 for project building to its own folder. We initially tried a common output folder and this can lead to subtle and painful to find out-of-date references.

FWIW, we use project references for solutions, and although nuget is probably a better choice these days, have found svn:externals to work well for both 3rd party and (framework type) in-house assemblies. Just get into the habit of using a specific revision number instead of HEAD when referencing svn:externals (guilty as charged:)

Solution 3

Unload projects you don't use often, and buy a SSD. A SSD doesn't improve compile time, but Visual Studio becomes twice faster to open/close/build.

Solution 4

We have a similar problem as we have 109 separate projects to deal with. To answer the original questions based on our experiences:

1. How do you best handle references between projects

We use the 'add reference' context menu option. If 'project' is selected, then the dependency is added to our single, global solution file by default.

2. Should "copy local" be on or off?

Off in our experience. The extra copying just adds to the build times.

3. Should every project build to its own folder, or should they all build to the same output folder(they are all part of the same application)

All of our output is put in a single folder called 'bin'. The idea being that this folder is the same as when the software is deployed. This helps prevents issues that occur when the developer setup is different from the deployment setup.

4. Are solutions folders a good way of organizing stuff?

No in our experience. One person's folder structure is another's nightmare. Deeply nested folders just increase the time it takes to find anything. We have a completely flat structure but name our project files, assemblies and namespaces the same.

---

Our way of structuring projects relies on a single solution file. Building this takes a long time, even if the projects themselves have not changed. To help with this, we usually create another 'current working set' solution file. Any projects that we are working on get added in to this. Build times are vastly improved, although one problem we have seen is that Intellisense fails for types defined in projects that are not in the current set.

A partial example of our solution layout:

\bin

OurStuff.SLN

OurStuff.App.Administrator
OurStuff.App.Common
OurStuff.App.Installer.Database
OurStuff.App.MediaPlayer
OurStuff.App.Operator
OurStuff.App.Service.Gateway
OurStuff.App.Service.CollectionStation
OurStuff.App.ServiceLocalLauncher
OurStuff.App.StackTester
OurStuff.Auditing
OurStuff.Data
OurStuff.Database
OurStuff.Database.Constants
OurStuff.Database.ObjectModel
OurStuff.Device
OurStuff.Device.Messaging
OurStuff.Diagnostics
...
[etc]

Solution 5

We work on a similar large project here. Solution folders has proved to be a good way of organising things, and we tend to just leave copy local set to true. Each project builds to its own folder, and then we know for each deployable project in there we have the correct subset of the binaries in place.

As for the time opening and time building, that's going to be hard to fix without breaking into smaller solutions. You could investigate parallelising the build (google "Parallel MS Build" for a way of doing this and integrating into the UI) to improve speed here. Also, look at the design and see if refactoring some of your projects to result in fewer overall might help.

View more solutions

Comments

[Mauricio Scheffer]

+1 I also have problems with the common output folder solution. I didn't understand what "project references for solutions" means, please explain a little bit more...

[Michael Meadows]

Hm, was this downvoted for being wrong, or just for disagreeing? I can live with the former if you can tell me why.

[si618]

As in we use VS->Add Reference->Projects, instead of VS->Add Reference->Browse. Small point I know but some folks do it differently (and I think this causes more headaches). If you look at MSBuild csproj text you will see ProjectReference property instead of Reference.

[si618]

Agreed, I dislike downvoting without comment, so Michael you get my +1 to balance the equation ;-)

[si618]

btw, I personally don't like mucking around with configuration management for this sort of thing. Why? because if you accidentally commit your modified configuration, then your build server or other developers will be affected.

[Michael Meadows]

Agreed. Actually, the same problem applies with solutions with too many projects. :)

[Solaiman Mansyur]

Interesting answer! I think we zigged where you zagged. We have no solution folders at all and rely on project naming (projects are named the same as the namespace). All of our output goes into a single folder, which makes the developer setup much closer to the deployment one. If dependencies are set correctly then we don't have out-of-date references.

[Eyvind]

Thanks man, I'll be sure to check those out!

[Page]

It's worth noting that unloading a project is a per-user setting, so developers on your team can load only the projects they care about. This has really helped our team out.

[Florian Doyon]

aye, the common output directory leads to a lot of pain, especially when using resharper. Out of date references indeed.

[irperez]

I will say that I have this book and its awesome. It has helped me automate my TFS builds and the local dev builds very extensively. I'm now working on Incremental builds, and the book goes into the subject very deep. Worth the price. Thanks Sayed. Keep up the great work.

[Sayed Ibrahim Hashimi]

Thanks irperez for the comments

[Kevin]

Don't quite understand the problem with a common output folder if you use this with Project References.

[si618]

@Kevin, it's several years now, but from memory one example is two projects referencing the same assembly, say an external library which is not project referenced. All fine when they're on the same version, but then a new release of this library comes out, but only one project updates their reference, which version gets used in the common output folder?

[Michael Freidgeim]

You can use Solution Load Manager extension visualstudiogallery.msdn.microsoft.com/… to define what to not load by default

[Michael Freidgeim]

-1 for UNCONDITIONAL recommendation to disable CopyLocal. Set CopyLocal=false can cause different issues during deployment time. See my blog post "Do NOT Change "Copy Local” project references to false, unless understand subsequences." ( geekswithblogs.net/mnf/archive/2012/12/09/…)

[andreapier]

Would you mind sharing your custom msbuild task?

[BrunoLM]

Could "build to one output folder" cause problems when compiling with multiple threads?

[BrunoLM]

Could "build to one output folder" cause problems when compiling with multiple threads?

[fourpastmidnight]

Or what if your solution contains multiple "top-level" builds--e.g. web sites or executables which share many of the libraries--which are independently deployable? (Granted--this may be a case for solution splitting, but assume, for the moment, that this is not possible at this time) It wouldn't be feasible to compile to a single output directory. Wouldn't the advice then be: CopyLocal should be False for libraries but left to True for these "top-level" projects?