It can be fast:

Perhaps consider not using dotnet install script or is the option to contribute a fix to dotnet install script?

Hi @jetersen, we will try to resolve this problem.

Hi Team - any news on this?

Hello @PureKrome,

So far no updates

The problem is not reproduced anymore.

Based on multiple runs, the action does not take more than 15 seconds.
https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6729109167

Most probably, the root cause of the problem was an infrastructure issue that has currently been resolved.

In case the problem reoccurs, the solution is to avoid bulk copying to the OS drive, similar to the workaround applied for the same problem in the actions/setup-go: actions/setup-go#393

@jetersen did it help?

@dsame I do not agree with the assessment that it is not reproducible 😓
Even with cache available Windows Server 2022 is still 20 seconds slower.
Creating the cache is still 1 minute longer than time of Ubuntu when running Windows Server 2022.

So definitely an improvement but I feel like windows can perform better.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736238225
https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736262624

I don't think it is fair to say look it is fixed for the actions/setup-dotnet when we are talking about a simple if check to see if .NET 6 is already available on the actions runner image 😓

Testing with .NET 8 preview shows ubuntu with 7 seconds vs +30 seconds sometime a little less. For actions/setup-dotnet.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736383956/job/18311632176

While this issue remains open: #141 this will definitely not improve 😢