For a long time now, a standard piece of advice to authors of MSBuild .targets and .props files is to make sure you add your file path to the property $(MSBuildAllProjects). This is because MSBuild checks the paths listed in that property when it wants to determine whether a project file has changed and needs to be rebuilt. So if you wanted projects that use your .targets or .props to be rebuilt when your file is updated or edited, you added your full path to that property.

However, there were three problems with this:

1. Paths tend to be long and, especially with NuGet in the picture, there are now a lot of .targets and .props files that get mixed into a build. So the $(MSBuildAllProjects) property keeps getting bigger and bigger.
2. MSBuild keeps around all versions of a property. So not only could the final value of the property be really long, if there were, say 30 files added in one at a time, there are also 30 copies of the property as it is being built up, multiplying the memory cost of the property.
3. There is one instance of this property for each project in a solution. So if you have a lot of projects in a solution, you’re going to multiply things even further.

The end result was that on some larger solutions we’ve looked at, you end up with a non-trivial percentage of the managed heap devoted to just this one single property. And the thing is that 99% of the time we only really care about one file in that list — the file that was last modified, since that’s what MSBuild is going to check against.

So, starting in 16.0, MSBuild now will automagically prepend the last modified project/.targets/.props file to $(MSBuildAllProjects). So if the only reason you’re adding yourself to that property is to make sure that the project rebuilds when you’re touched and you only need to support 16.0+, you should stop adding yourself. We’re already doing this in our projects, and so should you, to help performance.

If you have issues with your project file or with the project system, you can always ping me or David Kean or other team members on Twitter. However, Twitter is not always the most ideal way to carry on support-type conversations, particularly if there needs to be a lot of back and forth.

As a result, I created a Gitter channel for the dotnet/project-system repo which can be a place to have those more in-depth conversation. I’ll be monitoring the channel and will try and pull in other people as needed if there are questions beyond my expertise. We’ll see if it can develop into a place where people can come to get their C#/VB/F# project questions answered. Hope to see you there!

I’ve been spending a lot of time lately looking at the performance of the Visual Studio project system for C# and VB. And something that’s come up more than a few times now is consumers of the automation interfaces (a.k.a. DTE) accidentally tanking Visual Studio performance when working with project references.

To step back and review for a moment, one of the fundamental jobs the project system has is to run what are called design-time builds to determine the full contents of a project. I talked about it more here, but the short version of the story is that a design-time build is a build that the project system runs in the background that doesn’t actually call the compiler, just captures everything that makes up the build. This information is then (primarily) used to initialize the language service that provides things like Intellisense. The problem is that if your build happens to be pretty large or slow, these design-time builds can hang the Visual Studio UI with these really annoying pauses.

So, what does that have to do with references? Well, one of the uses of design-time builds is to help the project system figure out exactly what the references in a project point to. Most project references don’t specify the full path of the thing that they point at. As a result, the project system usually needs to run a design-time build so it can understand exactly where a reference is going to point once MSBuild is done with it.

Again, most of the time you never really notice this going on, it just happens quietly in the background. But there are circumstances where it can become visible, particularly when a project has unresolvable references. An unresolvable reference is, basically, a reference that the design-time build can’t find. Maybe the assembly it points at got deleted. Maybe the package it points at isn’t available on NuGet. Maybe there’s some typo in the reference itself. Whatever the reason, sometimes projects have references that cannot be resolved no matter how many design-time builds you run.

Unfortunately, this can really bite unwary Visual Studio extension developers. Because when an extension asks for the path to an unresolved reference, the project system does it’s best to try and answer that question. And how does it do it? By running a new design-time build. And if there are other unresolved references? You’ll get a design-time build for each of them. Again, if the project is small, nobody will likely notice. But if the project is large or complex? Pauses and delays.

Thankfully, there is a solution. Instead just asking for a reference’s path like this:

foreach (Reference reference in vsProject.References)
{
    // Ack! This may cause a design-time build to happen and block the UI
    if (File.Exists(reference.Path))
    {
        // Do something....
    }
}

You can do this:

foreach (Reference3 reference in vsProject.References)
{
    // Whew. If the reference isn't resolved, we don't try to get the path
    if (reference.Resolved && File.Exists(reference.Path))
    {
        // Do something....
    }
}

(Note that you have to switch from using the Reference type to the Reference3 type to get to the Resolved property.)

We’ve already fixed two instances of this pattern internal to Visual Studio that were causing pauses in the UI, and we’re actively looking for others. If you’re an extension author, check your code for this pattern — it may fix pauses that your users were encountering!

(We’re also adding code to the project system to recognize situations where unresolved references are never going to resolve, and skipping the design-time builds in those cases. That should help unwary extension authors, but won’t fix cases that could possible resolve but aren’t for some reason.)

You can also follow me on Twitter here.

Part of my job on the Visual Studio project system lately has been looking at the speed at which Visual Studio opens solutions containing managed language projects (such as C# and VB). As with many things, over time this common operation has gotten slower, and we would like to put some spring back in it’s step since everyone (including us!) have to open solutions all day every day.

As we’ve started to look at the various things that go on when you open a solution, one of the most obvious things we had to look at is something called design-time builds. Design-time builds are probably one of the least known and least understood things that go on in Visual Studio, and yet they often can have a real impact on how fast the Visual Studio UI responds (and not just on solution load!). I thought I’d take a minute to explain what design-time builds are and why you should care about them.

The origins of design-time builds comes from the fact that the Visual Studio build system (aka MSBuild) is not a fully declarative system. That is, you can’t just look at a .csproj file or .vbproj file and immediately understand everything you might want to know about how that project is going to build. In particular, you might not know the following:

• Given an assembly reference in the project file, what assembly on disk is that reference going to actually refer to at compile time?
• Given a XAML file, what is the code that is going to be generated by the XAML compiler at compile time going to look like?
• Given a glob file pattern (*.cs), what files are actually going to be included at compile time?

And these questions aren’t just academic — if you’d like to get a nice Intellisense experience (or all the other editor enhancements that you get from the compiler), then the compiler has to be able to answer those questions before you ever get to compiling your project. If it can’t get those answers, then it can’t see all the code and assemblies that make up your project, and therefore it can’t give you help in the editor.

So, what to do? Well, obviously, if you need to know what’s going to happen in a build, why not just run it? And so you get design-time builds. Unbeknownst to most users, Visual Studio builds your projects a lot more than you think. Potentially every time you make a change to a project that will affect how the project is built, Visual Studio will fire off a design-time build in the background. Now, there are a few differences in how design-time builds work from regular builds. In particular:

• The design-time build doesn’t actually run the C# or VB compiler because it doesn’t need to produce the actual output (i.e. dll or exe). It just needs to know how the build would be run. So instead of, say, calling csc.exe, it will just tell MSBuild to let it know what it would have asked csc.exe to compile without actually compiling it.
• The design-time build runs a slightly different set of MSBuild targets from a regular compile. This allows skipping things that aren’t needed in a design-time build, plus it allows the project system to run some additional targets (if needed) to provide extra information that the project system might need for, say, the Solution Explorer.

Design-time builds have two obvious issues. First, if they’re slow, it’s going to slow down Visual Studio but you won’t be able to tell where the problem is coming from. For example, a common place where slow design-time builds show up is switching between configurations. If you switch a large solution, say, from Debug to Release in Visual Studio, you might notice quite a long pause in which you can’t do anything in the UI. This is usually due to the configuration change kicking off a whole bunch of design-time builds to react to the fact that things in the project now might look different under the new configuration.

The other issue is if a design-time build fails. Since the compiler and the project system rely on design-time builds to accurately understand the contents of your solution, if design-time builds fail, things might start going wrong in the Visual Studio UI. The Solution Explorer might not show all of your files, or it might show them in the wrong place. Intellisense might not show you everything available, or it might show you nothing at all. You might get weird errors in the Error List. Often these kinds of problems can be traced back to a failing design-time build. The problem, as with performance issues, is that there’s no visible indication that that’s what the problem is.

So… Design-time builds are a necessary evil that can really mess things up if they go wrong. What can we do about it? Stay tuned…

You can also follow me on Twitter here.