Long delay before Visual Studio starts to build

Question

I have a solution with 50 projects, and each project has a minimum of 100 files (which I think is relevant).

The issue is when I build the solution, or a single project, that there is a delay of 5 to 10 seconds before the "Build Output" window gets written to. Setting the "Build Output" verbosity to "Diagnostic" does not give any indication as what the cause of the delay is. This delay even occurs when no files have been changed (previously built).

=== Build: 0 succeeded, 0 failed, 10 up-to-date, 0 skipped ==========

When there are changes, in the Build Output, it says the build took approximately 2 seconds to complete, however the end-to-end takes roughly 7 to 12 seconds.

Build output:

1>(omitted)
1>Time Elapsed 00:00:01.99
========== Build: 1 succeeded, 0 failed, 9 up-to-date, 0 skipped ==========

MSBuild:

Build succeeded.
     0 Warning(s)
     0 Error(s)

 Time Elapsed 00:00:02.17

 C:\Projects\SharedKernel.Tests>

Running MSBuild through the command line has no such delay, the 2.17 seconds is the time when pressing on the keyboard to completion.

From what I can tell, the msbuild tasks themselves execute quickly in Visual Studio, but it seems Visual Studio is doing something behind the scenes before the msbuild tasks start that is causing this delay.

When I inspect Visual Studio (devenv.exe) though Process Monitor I notice calls to CreateFile, QueryDirectory, and CloseFile for every file and folder in the project and the project's dependencies. This seems to correlate to the delay when looking at the timeline.

How do I reduce the delay from when I start build the build process from within Visual Studio (right click on project > build), to when the build actually occurs?

I looked at the following answers for resolution, however they either do not reduce the delay or are simply not applicable:

When you "Build" a solution as apposed to "Re-Building" the solution it only rebuilds files (.exes and such) that have changed, thus if you make a small changed it would take much longer for it to check over all the files within your solution looking for changes than it would to write those small changes (the actual building). This could be the slight delay you're experiencing. — CalebB, Mar 04 '15 at 21:31
I have a considerable delay when doing a "Build", even if no files have changed. The delay is longer when doing a "Build" on the "Solution". My particular example is when doing a "Build" on a single unit-test "Project". — Matthew, Mar 04 '15 at 21:42
Even if nothing has changed it will still look over the solution or project for changes. — CalebB, Mar 04 '15 at 21:44
I understand that, my question is how to reduce the delay, especially since doing msbuild through the command line gives me the same output without the delay. — Matthew, Mar 04 '15 at 21:45
Before it can figure out *what* needs to be built, it needs to look at 5000 files and retrieve their timestamps. How long that takes greatly depends on whether that info is present in the file system cache. With the obvious angle that you'll complain when it isn't. Multiplied by the speed of your storage device. Forcing it to always have to look at 5000 files is a fairly basic failure to organize. It will do what you ask it to do, just don't expect it to be enthusiastic about it. Perceived VS problems are always located in the corner where it stops being Visual. And yes, it isn't. — Hans Passant, Mar 04 '15 at 22:42
With regards to "failure to organize": if you really need that many projects, try copying the output files from each project build into a standard bin directory, using a build event. Then create solutions that have only a few projects in them, using the files in the bin directory for linking to external binaries (i.e. change some projects from internal to external, depending on the needs of each solution). You probably need to create more solutions. — Frank Hileman, Mar 04 '15 at 23:31
@HansPassant What is an appropriate number of files / projects for a solution? — Matthew, Mar 04 '15 at 23:58
It is one less than the number that makes me [pick up a sword](http://xkcd.com/303/). I don't like swords that much. — Hans Passant, Mar 05 '15 at 00:29
@HansPassant I don't know how that helps me to solve my problem. The fact is that when compiling through msbuild it does not have a delay. Msbuild is able to detect file changes and rebuild dependencies if appropriate, so I would like to know what Visual Studio is doing different. — Matthew, Mar 05 '15 at 05:36
Here is another caveat to pay attention to: http://blogs.msdn.com/b/msbuild/archive/2008/02/11/what-s-up-with-xxx-sln-cache.aspx — granadaCoder, Mar 05 '15 at 16:10
I'm curious whether 7-12 seconds is unreasonable. Is it really that big of a deal? I have much smaller solutions with fewer files that take 30-40 seconds to build on an SSD, and I think that's still pretty impressive. — Cᴏʀʏ, Mar 10 '15 at 20:29
It's a big deal when you're doing TDD and running tests every 15 - 30 seconds. — Matthew, Mar 10 '15 at 20:32

score 1 · Answer 1 · answered Mar 11 '15 at 17:42

I think your problem is "I have a solution with 50 projects". In my experience this should not be used for development. This should only be used for a build server. So what I would do is, make several solution files. One big with all projects for the build server, and several ones with just a few projects for development. The packaging of this several solutions should be guided by what often changes together. If the answer is everything I would question the project structure.

Because I do not realy answer your question what exactly vs does in comparison to msbuild, I would normaly write this as a comment. But my reputation is not enough right now (working on that) but because no one else recommended this, I thought it would passibly be worth an answer. Or is this just too obvious that nobody pointed this out? Then please forgive me.

score 0 · Answer 2 · answered Nov 15 '19 at 00:25

Visual Studio has its own way of checking whether a project is up to date or not. This can avoid expensive calls to MSBuild, and in general saves a lot of time when only a subset of projects need to be built.

This issue is pretty old, and these days disks tend to be faster, but the comments above are correct. VS must test the timestamp of every input and output to the project to determine whether things are up to date or not. If you have a very large number of inputs/outputs this can take a while, especially if you have slow disks.

Newer versions of VS have improvements to the up-to-date check. You can read more about the fast up-to-date check used by SDK-style projects here:

https://github.com/dotnet/project-system/blob/master/docs/up-to-date-check.md

score 0 · Answer 3 · answered Jul 04 '20 at 10:09

I had the same issue. Unloading all the projects you don't actively need will help. I managed to reduce the time before build start from about 9 seconds to 1 doing this.

I guess this is more of a workaround than a solution, but it helps.

To unload a project, right-click it and select "Unload Project".

Long delay before Visual Studio starts to build

3 Answers3