Visual Studio Toolbox: Accelerate your builds of SDK-style .NET projects
The Visual Studio Toolbox show helps you become a more productive developer by focusing on tooling in and out of Visual Studio. Our latest episode of VS Toolbox (available both on Learn and YouTube) features Drew Noakes from the .NET team. He demonstrates how you can dramatically reduce build times for SDK-style .NET projects.
What is build acceleration?
Build acceleration for .NET SDK style projects is an opt-in feature that directs Visual Studio to only build projects that had modifications while skipping projects that were unchanged. Enabling Build Acceleration can reduce incremental build times by up to 80% for SDK-style .NET projects.
To enable build acceleration in your solution, add or edit a top-level Directory.Build.props file to include the following:
<Project>
<PropertyGroup>
<AccelerateBuildsInVisualStudio>true</AccelerateBuildsInVisualStudio>
</PropertyGroup>
</Project>How does build acceleration work?
Visual Studio uses MSBuild to build .NET projects. There is some overhead associated with calling MSBuild to build each project, so Visual Studio uses a “fast up-to-date check” (FUTDC) to avoid calling MSBuild unless needed. This FUTDC can quickly determine if anything has changed in the project that would cause a build to be required.
Sometimes, the FUTDC identifies that no compilation is required, yet identifies some files need to be copied to the output directory, either from the current project or from a referenced one. Historically in this scenario, the FUTDC would call MSBuild to build the project, even though no compilation was required. This was done to ensure that the files were copied to the output directory. With the build acceleration feature, Visual Studio will perform these files copies directly rather than calling MSBuild to do them.
Learn more about build acceleration on the VS Toolbox show!
Check out the Visual Studio Toolbox episode below to see Build Acceleration in action and go try out the new feature!
Light
Dark
20 comments
Why this isn’t the default? there must be a catch? Compatibility issue?
See https://github.com/dotnet/project-system/issues/9106
There are a few edge cases where it might not work reliably, and causing people’s builds to break is never an option. We are investigating what it’ll take to turn it on by default though, as pointed out by Manuel in a sibling comment.
> For example, if a project’s build has post-compile steps that are important to the correct functioning of your project, then build acceleration will not correctly reproduce those steps when it bypasses MSBuild. https://github.com/dotnet/project-system/blob/main/docs/build-acceleration.md#limitations
Would that imply using ilmerge/ilrepack (which runs after build) would be exactly the case when one shouldn’t turn on build acceleration?
Finally…
Most of the other non-Microsoft development platforms do just that, since 1978 I guess? What took you so long?
Can you also comment on why your ide is too slow? why does it keep hanging? I have servers with 256GB of ram and yet, IDE hangs. not just on one, but on all servers for all my clients.
Shouldn’t such feature be in MSBUILD itself as well?
I doubt there is much investment going into MSBUILD since the “new” build mechanism is dotnet build, so this seems like a incremental step to increase performance while switching from MSBUILD to dotnet build still isn’t feasable and dotnet build may include this feature.
” … dotnet build uses MSBuild to build the project, …”
https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build
thanks, didn’t know that.
even reading https://stackoverflow.com/questions/66349892 it doesn’t seem like the case.
eg. why is dotnet build limited to only sdk projects, when msbuild can build them all? if dotnet build is really using msbuild
MSBuild is a complicated beast. There are 2 versions of MSBuild. MSBuild and MSBuild Core. The difference between the 2 is that MSBuild is compiled using the .NET Framework and MSBuild Core is compiled using modern dotnet core. As you might have noticed, the dotnet sdk uses MSBuild Core which does not support .NET Framework projects while Visual Studio uses the original MSBuild in order to support .NET Framework applications and dotnet SDK style projects. Hope this helps
Visual Studio is a long-lived process that knows a lot about your project at the instant you request a build. It can perform a few quick checks and identify cases where we don’t have to invoke MSBuild within a few milliseconds. By contrast, MSBuild is more of a one-shot operation, where when a build is requested the project, all the props/targets files it imports (there are a lot) need to be read, all the file system globs need to be expanded (this can take a while), and a whole host of book-keeping happens before any productive work happens, or before it’s clear that no build is needed.
We are investigating whether we can bring some of these benefits to other areas too, so hopefully these performance benefits will appear in other situations too.
Really a nice feature, saves lot of time for developers.
What is with .NET tooling nowadays that we only get to change XML content directly instead of project properties like in .NET Framework?
The feature itself is welcomed, and thanks for it.
The current properties UI is per-project, meaning to apply this to all projects you’d need to make many edits (which would be a lot of clicking). Modifying the XML here is almost certainly faster than that, and has the added benefit that the property will automatically apply to any new projects you create in future.
That said, we’d like to create a better property editing experience for `Directory.Build.props` files, though we’re not clear on exactly how that would work. As an example of a challenge here, there can be many of these files, and they can apply to a subset of projects. We’d likely also want to show which properties were overridden in a given project, and allow that to be reset.
We’re investigating turning Build Acceleration on by default, in which case you wouldn’t need to edit the XML at all for this feature to work.
The basic problem you have there is that hiding things in an invisible Directory.Build.props file is a horrendous choice, period. Horrendous for discoverability, usability, and maintenance. So maybe… don’t do that?
If you’re UI first, UI centric, what you said is true. However, nowadays everything is kept in a Git repo, VS and VS Code can show files from anywhere in your folders and it is not hiding somewhere in a cryptic place in the file system.
It is unfortunate that this is limited to SDK style projects, since there are no built-in templates to create a .NET Framework SDK style project, and a .NET SDK project cannot be converted to a .NET Framework SDK project within Visual Studio. I have heard that one can be created by manually editing the project file, but that is not so straightforward, and is definitely not obvious to developers. With no support for that within Visual Studio itself, it makes it seem that it is actually NOT supported.
You’re right that targeting .NET Framework from SDK-style projects is not officially supported. That said, it generally works well, and many components of Visual Studio specify .NET Framework from SDK-style projects. While you do have to modify the project file (e.g. `.csproj`) manually, it generally only involves changing e.g. `net7.0` to e.g. `net4.8`.
That said, we are investigating bringing Build Acceleration to other areas of .NET.
How come targeting net48 and brothers are not officially supported? It wouldn’t be documented under “Supported target frameworks” then, I suppose? https://learn.microsoft.com/en-us/dotnet/standard/frameworks#supported-target-frameworks
Or is it being said particulary about build acceleration?
This latest development is a true revolution that saves us precious time and breath while waiting for those never-ending compilations. I personally tried out this feature, and let me tell you, it’s absolutely mind-blowing. But hey, let’s keep it real here. While it brings a wave of awesomeness, it still has a few quirks to iron out. Occasionally, it might play hide-and-seek with our code lint and raise some eyebrow-raising reference issues. And oh, PostSharp doesn’t always want to dance along. But fear not, with a little love and improvement, this feature has the potential to reach new heights. So let’s embrace the revolution, enjoy the benefits, and keep pushing for even greater enhancements!