June 22nd, 2023

Visual Studio Toolbox: Accelerate your builds of SDK-style .NET projects

Leslie Richardson
Program Manager

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!

Author

Leslie Richardson
Program Manager

Leslie is a Program Manager on the C# developer experience team, focusing primarily on improving the overall .NET and C# productivity experience and feature set.

20 comments

Discussion is closed. Login to edit/delete existing comments.

  • Shan, Jing Zhe

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

    Read more
  • Mark Dell

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

    Read more
    • Drew NoakesMicrosoft employee

      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.

  • Paulo Pinto

    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.

    • Drew NoakesMicrosoft employee

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

      Read more
      • Andy Patrick

        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?

      • Jorge Morales Vidal

        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.

  • SAIRAM KONURU

    Really a nice feature, saves lot of time for developers.

  • Maximilian Haru Raditya

    Shouldn’t such feature be in MSBUILD itself as well?

    • Drew NoakesMicrosoft employee

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

      Read more
    • Rand Random

      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.

      • Rand Random

        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

      • Ethan Lindemann

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

        Read more
  • Albert Zakhia

    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.

  • Rosdi Kasim

    Why this isn’t the default? there must be a catch? Compatibility issue?

    • Drew NoakesMicrosoft employee

      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.

      • Jānis Veinbergs DEAC

        > 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?