2

I have a large-ish Visual Studio 2010 solution (~110 C# projects). One project (let's call it 'A') is a console application that has about 6 dependencies on other projects and some 3rd party assemblies.

If I build project 'A' it builds the dependencies as expected.

If I right-click on project 'A' and choose Debug | Start new instance, it first builds the project, and then proceeds to build a whole lot of other projects too. Watching the Output window, it's like it keeps restarting the build process for each of these other project and their dependencies.

The problem is that the original project 'A' does not depend on these other projects (directly or indirectly) that Visual Studio is building before starting the debugger.

This means that it takes ages before the debugger is launched.

I have customised the .csproj files in some of the other projects but have not customised the 'A' project.

Command-line builds via msbuild all behave normally.

What would be causing Visual Studio to do this?

David Gardiner
  • 16,892
  • 20
  • 80
  • 117
  • Did you find a solution for this problem? I am having exactly the same issue and I have already wasted a day trying to fix this issue? – Hunter Feb 13 '13 at 19:44
  • 1
    Not completely. I seemed to have worked around the problem partly by re-creating some of the projects from scratch (and adding project references back). I did this with the theory that maybe some of the metadata in the .sln file was messed up. – David Gardiner Feb 13 '13 at 23:09

1 Answers1

2

This is caused due to MSBuild's reference-chain. Project A depends on Project B which depends on Project C, on so on.

You have couple of options:

  1. By default new reference made in the current solution marked with Copy Local=true. This process is one of the most time consuming during the build. Sometimes it makes sense to have only the topmost projects (.exe files) with the copy local property as lib projects don't get run from their own output folder anyways.

  2. In the solution Properties -> Configuration Properties - by default each project is marked for build. You can uncheck unrelated projects from the build. This setting will be saved in the .sln file so just make sure you don't check-in this modification - this may fail your CI builds.

EDIT:

  • To further analyze the build process, increase MSBuild verbosity: Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity and set to Detailed or Diagnostic. This will help you in tracing build outputs nuances.
KMoraz
  • 14,004
  • 3
  • 49
  • 82
  • 1
    I understand the reference chain you mention. That makes sense when I do a regular build - it builds the dependent projects as expected. What I don't expect is that when doing a Debug Instance, that it rebuilds unrelated projects. Why would the reference chain be different when you're debugging vs. a regular build? – David Gardiner Mar 18 '12 at 10:34
  • See update for how to analyze the build output. Basically VS has a built-in mechanism to detect changes. This feature serves the concept known as "Incremental Build". [Here's a related post](http://stackoverflow.com/a/9145250/147211). – KMoraz Mar 18 '12 at 11:59
  • Yes, a good suggestion. One problem with this build scenario is that each time it restarts the build process for those other projects, it clears the Output window too. So you only get the build output for the last built dependency - all the previous ones are lost. And to be clear these multiple build processes all happen sequentially after you do a single 'Debug Start New instance' – David Gardiner Mar 18 '12 at 22:52
  • You can persist the IDE output by running `devenv` from commandline: `devenv your.sln /build Debug /out vside.log` – KMoraz Mar 19 '12 at 08:54
  • No good. That just does a command-line build - just the same as building the solution from within VS. The scenario I describe only happens when you right-click on a project in the solution and choose 'Debug Start New Instance'. – David Gardiner Mar 19 '12 at 09:09
  • You can try `run` > `devenv /run your.csproj /out vside.log` – KMoraz Mar 19 '12 at 14:30