dotnet / dotnet/sdk

Installing dotnet 10 SDK slows down dotnet 8 builds by over 100%

Open
#52,236 4 comments 0 reactions 0 assignees View on GitHub
Area-CLI untriaged
Dominant language
C#
Stars
3.2k
Forks
1.3k
PR merge metrics
PR metrics pending

Description

### Describe the bug
Installing the .dotnet 10 SDK and then building a dotnet 8 project takes WAY, WAY longer than with dotnet 9 sdk.

Background: Very large project, takes ~140s to build on a clean repo. I just built a new, faster PC (should be about 15-20% better IPC and 40% better multicore).
Rider on the new PC felt like it was taking much longer to do things than normal. I disabled all the windows app protection, whitelisted the repos and sdk folders in windows security etc thinking it would be that, but no luck (did improve the debugger startup time though, post-build). Before I went to file a ticket with Rider, I gave plain old dotnet build a try just to be sure it was a Rider problem, and lo and behold my 140s build is 301s on the new PC. So I start investigating. Turns out I had dotnet 10 installed on new PC (along with dotnet 9, and dotnet 8 sdks). Old PC only had dotnet 8 and 9 sdks installed.
I thought, that couldn't possibly be it, because our project VERY SPECIFICALLY targets dotnet 8, so why would having dotnet 10 sdk impact my build time? that would be crazy.

And yet, after spending nearly a day trying everything under the sun besides dumping the whole msbuild logs (was going to be my last resort since this solution has 10,000 warnings so sifting through those logs will be a nightmare) - I figured first I'd try installing the dotnet 10 SDK on old PC (see repro steps). Lo and behold, it 2.5x'd the build time on the old PC instantly. Detailed context in case it somehow matters:

I have a (very large) project that takes ~140 seconds to build, C#, 110 csproj's or so. One Data project with a very large EFCore DB context and many migrations, so that csproj takes the longest because nobody broke the migrations out from the context, so it's a dependency for everything else.

### To Reproduce

(note these steps are on old PC, which did not have dotnet 10 SDK installed. The output of dotnet --list-sdks was
8.0.416 [C:\Program Files\dotnet\sdk]
9.0.304 [C:\Program Files\dotnet\sdk]
)
1. I run a powershell script to recursively delete all /obj/ and /bin/ folders in the repo because for whatever reason dotnet clean doesn't get everything.
2. I run dotnet clean .\MySolution.sln
3. I run dotnet build .\MySolution.sln (took 141 seconds, which is normal)
4. Install dotnet 10 sdk https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-10.0.101-windows-x64-installer (the exact version I have installed now on both PCs).
5. dotnet --list-sdks now includes 10.0.101 [C:\Program Files\dotnet\sdk]
6. Run PS script that deletes all /bin/ and /obj/ recursively.
7. Run dotnet clean .\MySolution.sln
8. Run dotnet build .\MySolution.sln (takes 342.4 seconds, lmao). 200 of those seconds are spent on just the large EF migrations-containing csproj (which would normally be < 100 seconds, but still by far the longest before). This indicates to me it shouldn't be a parallelism problem, I'm building individual csprojes at less than half speed with net10 sdk installed.

How and why would the net10 sdk destroy my net8 build times?

Reproduces in JetBrains Rider.
Reproduces on the dotnet CLI.

Core of Directory.Build.props that all csprojs inherit (besides the .sqlproj's):
```
net8.0
latest
$(MSBuildThisFileDirectory)
True
false
false
win-x64
$(MyRuntime)
true
false
en
Library
```

Doubt relevant, but specs:
Old machine: Intel i9-12900KF 16core/24thread, 128 GB DDR5, 8 GBps WD SSD
New machine: AMD Ryzen 9 9950X3D 16core/32thread, 192 GB DDR5, 12 GBps WD SSD

Both win11 pro

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.