v3.0.0 results in dotnet builds 2x slower than v2

[dylan-smith]

Description:
We just recently upgraded to v3 of this action and it resulted in significantly slower dotnet builds. NOTE: It's not the setup-dotnet action that is slow, but the subsequent build step.

Task version:
v2 is fast, v3.0.0 is slow

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Repro steps:
I created a small workflow that demonstrates the problem: https://github.com/dylan-smith/setup-dotnet-repro/blob/main/.github/workflows/blank.yml

It has a build-v2 job and a build-v3 job, the only difference is the version of the setup-dotnet task in them. All they do is checkout a dotnet repo, setup-dotnet, then run a dotnet publish command. The dotnet publish command is significantly slower when setup-dotnet@v3 is used.

steps:
- uses: actions/checkout@v3
  with:
    repository: github/gh-gei

- name: Setup .NET
  uses: actions/setup-dotnet@v2
  with:
    dotnet-version: 6.0.x

- name: Build
  run: dotnet publish src/ado2gh/ado2gh.csproj -c Release -o dist/win-x64/ -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true --self-contained true /p:DebugType=None /p:IncludeNativeLibrariesForSelfExtract=true

Windows/Ubuntu runners are more than 2x as slow when using setup-dotnet@v3. Mac runners don't seem to be affected.

Ubuntu: 47s -> 97s
Windows: 96s -> 256s
Mac: 135s -> 139s

The workflow run/logs can be seen here: https://github.com/dylan-smith/setup-dotnet-repro/actions/runs/4609178383

Expected behavior:
I wouldn't expect the version of setup-dotnet to affect dotnet build times, or if it did I would expect newer versions to improve build perf not decrease it.

[dylan-smith]

Our fix for the time-being is we're rolling back to setup-dotnet@v2. This obviously isn't a long-term solution.

[IvanZosimov]

Hi, @dylan-smith 👋 As we discussed, you need to add global.json file to your repository and set up the required version of .NET there. To make it more comfortable to work with the action, instead of setting dotnet-version input, you can set global-json-file input, and the action will read and install the .NET version from the global.json you specify in the input. I'm going to close this issue now, if you have any additional questions feel free to ask them.

[dylan-smith]

Thanks for the help @IvanZosimov . To make sure I understand what's going on here (and for the benefit of any future travelers that land on this issue), I'll try and sum up my understanding.

When building with dotnet there is the .Net version that you are targeting - which is specified in the csproj. There is the .Net SDK version that you are using to build it (not necessarily the same as the target), and this is specified in a global.json file, and if not present it will use the latest SDK version available on the machine.

setup-dotnet doesn't set/pin either of these versions for you, instead it simply installs a specific version of .Net onto the build runner machine.

It seems the slowdown I was seeing was due to a difference in perf between using .Net SDK v6 vs v7. I was able to confirm this by adding a global.json forcing SDK v6 and the times became similar (setup-dotnet@v3 became faster to match the perf of v2).

What I don't understand is what was going on with setup-dotnet@v2, it seemed that it was using .Net SDK v6 (the same version I specified in the dotnet-version arg) despite .Net SDK v7 being present on the machine, and no global.json present.

It would be nice if there was a way to make setup-dotnet@v3 behave in a similar way to v2. Through some combination of args be able to say "install this version of .Net and make sure that it is used for all subsequent dotnet commands (e.g. generate a global.json file for me)".

[IvanZosimov]

Thanks for the feedback, @dylan-smith 👋 We've started the internal investigation on this topic. We will keep you in the loop.