简体   繁体   中英

Long delay before Visual Studio starts to build

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:

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.

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

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".

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM