How to configure VS to compile only changed code

Question

I have very big solution, and it compiling every time I\'m tring to debug.
So I know that I can to disable building of all projects at all in solution configuration, but is

Answer 1

You should use "Build Solution". Check out this link http://kiranpatils.wordpress.com/2008/04/02/what-is-the-difference-between-build-and-re-build-in-visual-studio-net/

Answer 2

1/ Check the build log in a verbose mode (Tools -> Options -> Projects and Solutions -> Build and Run).

2/ Among the possible errors, there may be a dll in "copy local" mode that causes the problem, if this is the case go to the project references, find the dll and set the "copy local" value to false.

[I found these solution here] https://oz-code.com/blog/net-c-tips/visual-studio-keeps-rebuilding-projects-no-good-reason

Answer 3

Visual Studio actually does that out of the box if you do a Build (not a Rebuild). However, it'll deal with some project types better than others. For example a setup or deployment project will always be built.

You could unload any project that you don't need to speed up the build.

Additionally, I find it works well to start the application without debugging and attach the debugger once the application is running. From what I can tell this minimizes the number of debug symbols being loaded to what is actually being used by the running application.

As far as I know MSBuild (the build engine used by VS) will auto-detect what to rebuild based on what files have been changed. So make sure you don't have any generated files that are updated with each build. For example, when you update the (assembly) version using source control meta data. Any changed file will trigger a build of all the projects that use it and all the projects that depend on them. A setup like this will effectively rebuild most of your application every time.

Answer 4

I'll add this as no one has mentioned it - if you have an installer project in your solution, that project will be rebuilt every time you rebuild or run the program, even if no other projects have changed. As building installer projects can take a significant amount of time (~45 seconds on my machine, for my medium-sized project), this is a problem.

To solve, simply go into the configuration manager (right-click solution-->properties-->configuration properties) and uncheck "build" the installer project when under debug mode.

Answer 5

As Marnix and Anton already said this is what VS normally does. But if you have a lot of projects within your solution which depend on each other and you make changes to a component which will be used by all or most of the other projects it has to build also the others again to make sure everything works as expected.

Update

So if it starts to recompile even if you didn't make any change we need to find out how VS tries to find out what it needs to do on a incremental build.

For this it simply checks the datetimes of every file and if there are any changes. If yes, recompile that file and all its dependents (e.g. changes in a stdafx.h will result in a complete rebuilt, cause normally every source file will reference to this one).

But there are also exceptions to this behaviour. A setup project for example will always rebuilt, even if there are no changes made (due to this fact I normally exclude the setup project from the build process and start it only manually when needed).

So if you only have C/C++, C#, VB etc. project which normally support incremental builds there must be something that changes between two builds, even if you don't change anything.

Here are some possibilities:

• A pre or post build command that make a change to a source file
  • this can maybe an auto-update of adding the revision number from your repo into a resource of AssemblyInfo file.
  • or a copy/delete command that makes some changes in your directory structure (I used this one time to delete the output directory in a pre-build command to force a rebuild on every build).
• An auto incrementer of the assembly version
  • maybe by using [assembly: AssemblyVersion("1.0.*")] or some other external process to increase the build number

If one of the above steps happens to a module from which all or most of your other projects depends on than everything needs to be rebuilt.