Why is the "DotNetCore" build task so slow?

Question

We've have a number of.Net Framework 4.x solutions, some of which were recently migrated to.Net 6. As part of this work I created build pipelines for the new solutions, however these are extremely slow when compared to the builds of the.Net Framework solutions.

The slow build task is ".Net Core" ("DotNetCoreCLI@2"), and is used in three places: "restore" command to restore the solution's NuGet packages, "build" command to build the solution, and "test" command to run the solution's unit test projects.

Taking one solution as an example (around 50 projects), these are the approx timings:

• restore: 1m20s
• build: 3m
• unit tests: 3m

And here are the approx. timings from builds of the.Net Framework solution, which you can see were substantially faster:

• restore: 9s - using the "NuGet" ("NuGetCommand@2") task
• build: 1m13s - using the "Visual Studio Build" ("VSBuild@1") task
• unit tests: 40s - using the "Visual Studio Test" ("VSTest@2") task

I believe the latter two tasks utilise VS2019 (installed on our on-prem Azure DevOps server), and I recently found this 3rd-party marketplace build task, which is a VS2022 equivalent of these tasks. I have updated the.Net6 build pipeline to use these instead of the "DotNetCoreCLI@2" build and test tasks (and I reverted to using "NuGetCommand@2" for the restore). The timings are now on a par with the.Net Framework build pipeline:

• restore: 10s ("NuGetCommand@2")
• build: 50s (marketplace task)
• unit tests: 32s (marketplace task)

I would prefer to use built-in tasks over marketplace tasks, but why is the "DotNetCoreCLI" task so slow? Am I missing something with regards to configuration, or is it just a case of newer technology not always equating to improved performance?!

Answer 1

Visual Studio tasks are pretty heavy and largely there for legacy support.

When making the jump to modern .NET, rule #1 is forget everything about the old way you build projects. When using .NET 6, you get a much better experience doing everything with the do.net CLI from NuGet package restoration ( do.net restore ) to testing ( do.net test ) and publishing an artifact ( do.net publish <ARGS> ). Use those in your build pipeline with the UseDotNet@2 and DotNetCoreCLI@2 pipeline tasks.

Very important to note, in Azure DevOps you can cache your NuGet dependencies so you don't have to download them unless they change.