I have a large c# solution file (~100 projects), and I am trying to improve build times. I think that ‘Copy Local’ is wasteful in many cases for us, but I am wondering about best practices.
In our .sln, we have application A depending on assembly B which depends on assembly C. In our case, there are dozens of ‘B’ and a handful of ‘C’. Since these are all included in the .sln, we’re using project references. All assemblies currently build into $(SolutionDir)/Debug (or Release).
By default, Visual Studio marks these project references as ‘Copy Local’, which results in every ‘C’ being copied into $(SolutionDir)/Debug once for every ‘B’ that builds. This seems wasteful. What can go wrong if I just turn ‘Copy Local’ off? What do other people with large systems do?
FOLLOWUP:
Lots of responses suggest breaking up the build into smaller .sln files… In the example above, I would build the foundation classes ‘C’ first, followed by the bulk of the modules ‘B’, and then a few applications, ‘A’. In this model, I need to have non-project references to C from B. The problem I run into there is that ‘Debug’ or ‘Release’ gets baked into the hint path and I wind up building my Release builds of ‘B’ against debug builds of ‘C’.
For those of you that split the build up into multiple .sln files, how do you manage this problem?
In a previous project I worked with one big solution with project references and bumped into a performance problem as well. The solution was three fold:
Always set the Copy Local property to false and enforce this via a custom msbuild step
Set the output directory for each project to the same directory (preferably relative to $(SolutionDir)
The default cs targets that get shipped with the framework calculate the set of references to be copied to the output directory of the project currently being built. Since this requires calculating a transitive closure under the ‘References’ relation this can become VERY costly. My workaround for this was to redefine the
GetCopyToOutputDirectoryItemstarget in a common targets file (eg.Common.targets) that’s imported in every project after the import of theMicrosoft.CSharp.targets. Resulting in every project file to look like the following:This reduced our build time at a given time from a couple of hours (mostly due to memory constraints), to a couple of minutes.
The redefined
GetCopyToOutputDirectoryItemscan be created by copying the lines 2,438–2,450 and 2,474–2,524 fromC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targetsintoCommon.targets.For completeness the resulting target definition then becomes:
With this workaround in place I found it workable to have as much as > 120 projects in one solution, this has the main benefit that the build order of the projects can still be determined by VS instead of doing that by hand by splitting up your solution.