How to make VS 2010 skip the "build" of projects that have not changed?

Question

Our product has more than 100 projects (500 + ksloc production code). Most of them are C # projects, but we also use little C ++ / CLI to associate communications with native code.

Restoring the entire solution takes several minutes. It's great. If I want to rebuild the solution, I expect it to take some time. What is not good is the time it takes to create a solution after a complete overhaul. Imagine that I used a complete rebuild and now, without making any changes to the solution, I press Build (F6 or Ctrl + Shift + B). Why does it take 35 seconds if there were no changes? At the exit, I see that he began to "build" each project - he does not perform a real assembly, but does something that consumes a significant amount of time.

This delay is a pain in the ass. Yes, I can improve the time without using the build solution, but only by creating a project (Shift + F6). If I run an assembly project for a specific test project that I am currently working on, it will accept “only” 8 + s. It requires me to start building the project on the correct project (the test project also provided the assembly of the dependent verified code). At the very least, the ReSharper tester correctly recognizes that only this single project should be an assembly, and restarting usually only contains 8 + s compilation. My current Kata encoding: don't touch Ctrl + Shift + B.

Building a test project will take 8 seconds, even if I do not make any changes. The reason it takes 8 seconds is that it also builds dependencies = in my case, it builds more than 20 projects, but I only made changes to the unit test or one dependency! I do not want him to deal with other projects.

Is there a way to simply tell VS to build only projects in which some changes have been made, and projects depending on the changes (preferably this part as another build option)? I'm worried, you will tell me that this is exactly what VS does, but in different ways ...

I want to improve my TDD experience and reduce compilation time (in TDD, compilation can happen twice per minute).

To make this even more frustrating, I work in a team where most developers worked on Java projects before joining it. That way, you can imagine how angry they are when they should use VS, as opposed to full incremental compilation in Java. I do not need incremental compilation of classes . I expect that we will work with incremental compilation of solutions. Especially in a product like the 2010 Ultimate, which costs several thousand dollars.

I really don't want to receive answers like:

• Make a separate decision
• Upload projects that you don’t need.
• and etc.

I can read these answers here . These are not acceptable solutions. We do not pay for VS to make such compromises.

Answer 1

By default, Visual Studio will always build each project in your solution when starting one project. Even if this project is not dependent on any other project in your decision.

Go to the Tools section. Options | Projects and Solutions | Build and run and check the box "Only create run projects and Run dependencies". Since now, when you start your project (F5 key), Visual Studio will only build your launch project and those projects in your solution on which it depends.

Answer 2

Is there a way to just tell VS to build only projects where some changes have been made and projects depending on the changes (this part is preferable as another build option)? I worry you will tell me that this is exactly what VS does, but in different ways ...

Not really (you already understand that).

You are talking about a "build system." MSVS is not. This is an IDE that allows you to organize your assets in projects and solutions, and build. But this is not a build system. It will never be a build system (a long story, but a completely different technology is required).

In contrast, MSVS is an IDE for accelerated iterative development, including a debugging cycle (for example, "step by step" and "switching" to debbugger at system startup). That MSVS is "shining."

It will not and will never shine like an assembly system. This is not what was created for this. And that will probably never change (long story, even Microsoft will most likely agree).

I am not trying to be pretty, and I sincerely apologize for delivering this news. This answer also hurts me.

I expect incremental compilation of solutions to work. Especially in a product like the VS 2010 Ultimate, which costs several thousand dollars.

MSVS is an interactive debugging / development environment, not a build system (see above). Thus, you measure it in the scenario of a product for which it was not designed, and in which it will probably never function as you wish.

I really don't want to receive answers like:

• Make a separate decision
• Upload projects that you don’t need.
• and etc.

I can read these answers. These are not acceptable solutions. We do not pay for VS to make such compromises.

Your expectations are reasonable. I want them too. However, MSVS is not the product that will ever deliver this.

Again, I'm not trying to be pretty. If you want to invest in a “build system”, you can find value in using CMake to manage your configurations and export Makefiles (or something) to complete your “real” builds, but also to “export” *.vcproj and *.sln files when you want to work iteratively and interactively in an MSVS environment.

EDIT: Most likely you need an SSD (solid-state drive) for the build workspace to get a 10-fold increase in speed or a RAM drive for a 100-fold improvement in speed for build (without mocking, 64 MB of RAM on the LGA2011 connector gives you 32 MB of RAM, which we use.)

Answer 3

One thing you can do is break the application down into small solutions, each of which is a cohesive part. Build each solution separately. Let each solution use the output of the decisions it depends on, instead of using the source code.

This will reduce short feedback cycles for each component.

EDIT: Modified Solution

In addition, you will create an integrative assembly, which, instead of receiving all sources, compiling and testing, will receive binary assembly products of CI build components . This integrative build should start after each successful build of the component.

This assembly should be the binary equivalent of a complete assembly (which you should build every night anyway), but will take significantly less time to run, since it starts after the component increment and does not need to compile or get sources.

In addition, if you use an enterprise-level building system that supports the concept of distributing your assemblies between several agents, you can scale your efforts and reduce your entire CI cycle to the amount of time needed to build the longest component and check the integrative set (at most) .

Hope this helps.

Answer 4

Weighing is a bit late, but did you think you had different build configurations?

You can say that the visual studio does not create specific projects depending on the assembly configuration.

The developer can simply choose the configuration that matches the project they are working on.

Answer 5

Pretty old thread, but I can say that I had a small version of the same, and I upgraded to Visual Studio 2012, and the problems seem to be finally fixed. The RedGate.NET Demon solution mentioned above also works pretty well.

Answer 6

This is an old problem.

Use parallel assembly and SSD. See here (I think - google fast): http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx

Answer 7

I found a tool that basically does what I want (and even more): RedGate.NET Demon . This is probably the first version, because I ran into small problems in our big solution (problems with C ++ projects, problems with assembly switching goals and some others), but I really like it. I especially like the way it tries to track modified files in the VS IDE and restores only the affected projects.

Edit: .NET Demon has been removed because it is not needed for VS 2015. It still works with previous versions.