a blog on programming languages and other stuff…

Monthly Archives: December 2017

In my last couple of blog posts, I talked about the role that design-time builds play in Visual Studio performance. However, they are not the only way in which your project file can affect the IDE.

Before Visual Studio can do anything with your project (much less run a design-time build on it), we first have to load the project from its XML format and interpret that XML to create the in-memory representation of the project. But the MSBuild format isn’t purely static–you can specify conditions inside of the project file that governs whether other target files are imported, whether properties are set or not set, or whether items are included or not included in the build. So as MSBuild interprets the XML, it has to evaluate all those conditions to figure out what is really in the project.

And Visual Studio doesn’t only interpret your project when you open a solution, it often has to do this other times as well. For example, since a lot of things in a project file are conditioned on what build configuration (Debug vs. Retail) or platform you are building for, when you switch build configurations or platform Visual Studio may need to reevaluate the project. Or, for another example, if a project references a NuGet package that adds target files of its own, the project may need to be re-evaluated when that package is updated, in case something changed in those included target files.

Unfortunately, these evaluations aren’t necessarily free. Depending on the complexity of your project file, or of the target files it includes, it may take a little while to evaluate your entire project file. While this time is less noticeable than design-time builds in general, if you open a solution with a large number of projects it can really add up. And, unlike design-time builds, there is no cache that Visual Studio maintains of project evaluation results, so you pay the cost every time you open a project (or do something that forces a re-evaluation).

We’re thinking about ways to make this better, but in the interim we’ve been enhancing the Project System Tools extension to help users better understand the impact of evaluations. So now the Build Logging window will include evaluations as well as design-time (and regular) builds:

Right now evaluation logging only works for non-SDK projects (i.e. non-.NET Standard and non-.NET core projects) due to API limitations, but we hope to have it working for all projects very soon.

(You can also try out an experimental MSBuild evaluation profiler that’s currently sitting in a branch of MSBuild. We’re looking at moving that into the product in the near future as well.)