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!
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...
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?
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...
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.
Really a nice feature, saves lot of time for developers.