-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet workload
is broken on windows-latest runner image 20250113.1.0 when using SDK version 8.0.x
#11402
Comments
Possibly also affects Azure DevOps if dotnet/sdk#45931 is anything to go by, but I have no means to verify. |
All our dotnet builds are failing now with A simple way to reproduce it is to run jobs:
- job: MyJob
pool:
vmImage: 'windows-2022'
steps:
- checkout: self
- script: 'dotnet --info' Here is an extract of the logs:
|
Hi @bdach - Thank you for bringing this issue to our attention. We will look into this issue closely and will update you after investigating. Additionally, latest windows image version is going to roll out. Will update you on this. |
Any news here? We are stuck aswell.. |
Indeed the 2022 vmimage is broken all of a sudden. But the windows-2019 vmimage works. PS: I do use a global.json file to target the latest version of dotnet 8.x available in the windows-2022 image. |
I am seeing the same thing on a few private repositories as well. The |
Hi @bdach - We are looking into this issue closely and will update you on this. Appreciate your patience! cc: @fuzzzerd , @thomasbach-dk , @corentinvds , @ksidirop-laerdal |
Still no update? |
Hi @thomasbach-dk - We're not encountering the issue with the windows-latest. we'll keep you updated by monitoring for two days. Thank you for your support !
|
Well. I do. |
@kishorekumar-anchala I can't see what you're doing precisely, but I suspect that your attempt at reproduction may be accidentally using dotnet sdk 9.0 which appears to be unaffected. It's the 8.0 version that is broken here. Please find minimal reproducer at https://github.com/bdach/dotnet-breakage-reproducer. In particular the |
dotnet workload
is broken on windows-latest runner image 20250113.1.0dotnet workload
is broken on windows-latest runner image 20250113.1.0 when using SDK version 8.0.x
Hi @bdach - I tried with same workflow which is given in the repro steps , Kindly check the below workflow. thank you ! https://github.com/kishorekumar-anchala/runner-images-kishore/actions/runs/12906689108/workflow |
As stated above, that workflow used sdk 9.0 as seen in the output of It is required to create a |
Hi @bdach - tried with your code and did a small change it works , please try with below workaround. thank you !
Workflow URL : https://github.com/kishorekumar-anchala/dotnet-breakage-reproducer/actions/runs/12910058468/job/35999210886 |
The SDK version in While yes we could consider just cutting losses and changing things to run on sdk 9, it is a bit strange to see that the default windows runner apparently is not able to correctly run the current LTS version of the sdk. |
Per workaround suggested in actions/runner-images#11402 (comment). Applying this now as my hopes for a swift resolution without changes on our side are slim to none (read thread linked above in full to learn why).
Hi @bdach - it seems the issue with dotnet , i request you please submit a bug issue with the dotnet-sdk team . link : https://github.com/dotnet/sdk/issues Thank you ! |
I came here from a |
Everything worked fine until the release of window-2022 runner version 20250113.1.0. Since you did not introduce any new .NET SDKs in this version it´s hard to believe that it should be a .NET issue only. You did remove .NET 7 though, but that seems to have left the preinstalled workloads broken. |
I will also say that |
I am trying with windows-2019 as well. But my experience is that the runner is unbelievably slow. Did you experience anything like that? I also tried with windows-2025, but I´m struggling with installation of the maui workload: |
My sample size is very low and I generally mostly care about seeing green at all rather than how fast I see green, but from what low sample size I have I don't seem to notice it being that much slower than what we used to have before the build broke.
Yeah I also tried |
Per workaround suggested in actions/runner-images#11402 (comment). Applying this now as my hopes for a swift resolution without changes on our side are slim to none (read thread linked above in full to learn why).
Installing .NET SDK 7.0.x before installing workloads seems to fix the issue.
|
@fuzzzerd trying to get back to where i started i just want best setup for Iracing and watching YouTube. i also stream a few sites to buy stuff like eBay. i have a p870dmg-3 Clevo Euroccom Evoc with i7 6700k and dual GTX1080's in SLI and i have the premamod unlocked bios those are my specs if that helps any. I need the best possible Iracing setup. |
Description
First noticed via android builds starting to fail intermittently out of nowhere after no changes on our behalf.
Upon throwing several workarounds at the problem and failing every one (which was made even more difficult by the fact that the build is half-rolled-out, therefore the failure only occurs in ~15% of builds queued, and this is not the first time this sort of thing has happened, by the way), I can't come to a conclusion other than just say that
dotnet workload
has become terminally broken somehow, because even a baredotnet workload search
fails with the exact same error.Platforms affected
Runner images affected
Image version and build link
Is it regression?
Yes, last working version was 20250105.1.0
Expected behavior
(https://github.com/bdach/osu/actions/runs/12805144936/job/35700930330#step:5:1)
Actual behavior
(https://github.com/bdach/osu/actions/runs/12805144936/job/35701092126#step:5:1)
Repro steps
I believe this job definition should be sufficient to reproduce and minimal enough to not require testing on the original project:
As long as you actually get lucky enough to run on the correct runner image version, that is.
The text was updated successfully, but these errors were encountered: