[9.0-preview.7] Microsoft.DotNet.MSBuildWorkloadSdkResolver fails with dotnet workload or build on Windows #42211
Comments
dotnet-issue-labeler
bot
added
Area-Workloads
untriaged
martincostello
changed the title
|
This certainly looks bad! I tried to reproduce it, and I'm having a little trouble. Any thoughts on what I'm doing wrong? Windows --> windows powershell I cloned your repo, checked out that commit, and verified that it included the global.json change to update the SDK. I tried building, and it failed because of Join-Path. Apparently windows powershell is a bit out-of-date, and it doesn't permit Join-Path with more than 2 inputs, so I cobbled together several Join-Paths wherever you used one for > 2 arguments, and now it builds... But it builds successfully with one warning that doesn't look relevant. I suspect you have a workload set in an unexpected place, but I'd love to know more about it. Here's my best guess: Mostly coincidentally, I think your current problem will be mitigated by #41996 but only because that PR basically says "if you didn't ask for a workload version, we shouldn't give you a workload version," which means we wouldn't go looking for a manifest that was never installed. Can you verify that you have a file named *.workloadset.json under a folder named 9.0.100-preview.7.24367.5 in your dotnet directory (under sdk-manifests\8.0.100\workloadsets, I think, but I haven't checked yet) and that it specifies the 8.0.1/8.0.100 version of microsoft.net.sdk.aspire? And can you try manually deleting that (along with parent folder(s) until they're not empty) and see if that resolves your issue? |
|
I typically just have the dailies ingest in the background in CI, rather than play around with them locally (unless I want to play with a brand new API that's just dropped). As these PRs are a failing, I haven't been pulling them down locally as I just pull from the target branch ( Maybe it's something about the default SDK versions installed on the Windows GitHub Actions runners and actions/setup-dotnet works? "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command & 'D:\a\_actions\actions\setup-dotnet\v4\externals\install-dotnet.ps1' -SkipNonVersionedFiles -Runtime dotnet -Channel LTS
dotnet-install: Remote file https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.7/dotnet-runtime-8.0.7-win-x64.zip size is 33315858 bytes.
dotnet-install: Downloaded file https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.7/dotnet-runtime-8.0.7-win-x64.zip size is 33315858 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Extracting the archive.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install/windows#dependencies
dotnet-install: Installed version is 8.0.7
dotnet-install: Installation finished
"C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -Sta -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command & 'D:\a\_actions\actions\setup-dotnet\v4\externals\install-dotnet.ps1' -SkipNonVersionedFiles -Version 9.0.100-preview.7.24367.5
dotnet-install: Remote file https://dotnetbuilds.azureedge.net/public/Sdk/9.0.100-preview.7.24367.5/dotnet-sdk-9.0.100-preview.7.24367.5-win-x64.zip size is 265904062 bytes.
dotnet-install: Downloaded file https://dotnetbuilds.azureedge.net/public/Sdk/9.0.100-preview.7.24367.5/dotnet-sdk-9.0.100-preview.7.24367.5-win-x64.zip size is 265904062 bytes.
dotnet-install: The remote and local file sizes are equal.
dotnet-install: Extracting the archive.
dotnet-install: Note that the script does not resolve dependencies during installation.
dotnet-install: To check the list of dependencies, go to https://learn.microsoft.com/dotnet/core/install/windows#dependencies
dotnet-install: Installed version is 9.0.100-preview.7.24367.5
dotnet-install: Installation finished |
|
We're having issues reproducing this error. I mentioned what I did, and @baronfel looked into your github action and tried to reproduce it from there but also had difficulty. It sounds like you haven't actually reproduced this locally. Can you try and see what comes of it? If it reproduces for you, we can try to see what's different between our setup and yours, and if it doesn't, we can look into what's different between CI and local builds. Part of what's confusing is that the manifest that it references apparently should be installed already, so the fact that it can't find it means a poor error message, a broken install, or we're looking in the wrong spot. I was at least able to verify that the size of the SDK CI installed was the same as the size of the SDK that I installed, though it could've theoretically failed in extraction. |
|
I can't repro this locally either. If I checkout the branch and run {
"Microsoft.NET.Sdk.Android": "34.99.0-preview.6.340/9.0.100-preview.6",
"Microsoft.NET.Sdk.iOS": "17.2.9714-net9-p6/9.0.100-preview.6",
"Microsoft.NET.Sdk.MacCatalyst": "17.2.9714-net9-p6/9.0.100-preview.6",
"Microsoft.NET.Sdk.macOS": "14.2.9714-net9-p6/9.0.100-preview.6",
"Microsoft.NET.Sdk.Maui": "9.0.0-preview.6.24327.7/9.0.100-preview.6",
"Microsoft.NET.Sdk.tvOS": "17.2.9714-net9-p6/9.0.100-preview.6",
"Microsoft.NET.Workload.Mono.ToolChain.Current": "9.0.0-preview.7.24365.1/9.0.100-preview.7",
"Microsoft.NET.Workload.Emscripten.Current": "9.0.0-preview.7.24352.2/9.0.100-preview.7",
"Microsoft.NET.Workload.Emscripten.net6": "9.0.0-preview.7.24352.2/9.0.100-preview.7",
"Microsoft.NET.Workload.Emscripten.net7": "9.0.0-preview.7.24352.2/9.0.100-preview.7",
"Microsoft.NET.Workload.Emscripten.net8": "9.0.0-preview.7.24352.2/9.0.100-preview.7",
"Microsoft.NET.Workload.Mono.ToolChain.net6": "9.0.0-preview.7.24365.1/9.0.100-preview.7",
"Microsoft.NET.Workload.Mono.ToolChain.net7": "9.0.0-preview.7.24365.1/9.0.100-preview.7",
"Microsoft.NET.Workload.Mono.ToolChain.net8": "9.0.0-preview.7.24365.1/9.0.100-preview.7",
"Microsoft.NET.Sdk.Aspire": "8.0.1/8.0.100",
}Something that does stand out here (well, I had a squiggle when I opened the file in VS Code) regardless of whether it's actually related to this issue, I notice that the content isn't strictly valid JSON due to the trailing comma. |
|
I see the comma is catered for, so it's not that: |
|
This is what's in the corresponding
|
|
Looks like the GitHub Actions runner comes with |
|
I also noticed that between the last successful build with the prior working version and the latest, the GitHub Actions runner image has changed from I re-ran it to pick up the new runner image to see if that is the motivating factor, but it still passes. |
|
Messing about in this PR it seems that the GitHub Actions runner has aspire Installed Workload Id Manifest Version Installation Source
---------------------------------------------------------------------
maui-windows 8.0.61/8.0.100 VS 17.10.35027.167
maccatalyst 17.2.8053/8.0.100 VS 17.10.35027.167
ios 17.2.8053/8.0.100 VS 17.10.35027.167
android 34.0.95/8.0.100 VS 17.10.35027.167
wasm-tools 8.0.7/8.0.100 VS 17.10.35027.167
aspire 8.0.0/8.0.100 VS 17.10.35027.167
Use `dotnet workload search` to find additional workloads to install.Then if I run actions/setup-dotnet for both Installed Workload Id Manifest Version Installation Source
---------------------------------------------------------------------------------
android 34.0.113/8.0.100 SDK 8.0.300, VS 17.10.35027.167
aspire 8.0.2/8.0.100 SDK 8.0.300, VS 17.10.35027.167
ios 17.2.8078/8.0.100 SDK 8.0.300, VS 17.10.35027.167
maccatalyst 17.2.8078/8.0.100 SDK 8.0.300, VS 17.10.35027.167
maui-windows 8.0.61/8.0.100 SDK 8.0.300, VS 17.10.35027.167
wasm-tools 8.0.7/8.0.100 SDK 8.0.300, VS 17.10.35027.167
Use `dotnet workload search` to find additional workloads to install. |
|
I also notice that the sorting there isn't stable - is it worth me opening a PR to add a sort to |
|
I can't work out an obvious way to get |
|
I'm also running into this even with a super vanilla setup: https://github.com/MichalStrehovsky/bug42211/pulls There's almost nothing in the repo, just a hello world console app and a hello world Github action setup. |
|
Thanks to dotnet/runtime#69951 (comment) I've been able to unblock myself from this issue by adding the following as the first step in my GitHub Actions workflow jobs: # HACK Workaround for https://github.com/dotnet/sdk/issues/42211
- name: Update .NET Aspire workload
if: runner.os == 'Windows'
shell: pwsh
run: |
$manifest = @'
{
"microsoft.net.sdk.aspire": "8.0.1/8.0.100"
}
'@
$manifestPath = Join-Path ${env:RUNNER_TEMP} "workload-manifest.json"
$manifest | Out-File -FilePath $manifestPath -Encoding utf8
dotnet workload update --advertising-manifests-only && `
dotnet workload update --from-rollback-file $manifestPathObviously not ideal, but is better than being completely broken. |
I guess I'm still confused as to why that should be so problematic. I would've thought it would have installed the 8.0.1 version along with the SDK. Perhaps there's a bug in the install script where it checks if that manifest (or perhaps a version of that manifest with the same major version?) is already installed and skips installing it if so? I wouldn't have expected that.
That sounds like a pretty reasonable change to me!
What commands did you try to run? In general, I think of there being two modes: "give me the latest" and "I want exactly this/these version(s)." You only get the latter behavior if you request to update/install --from-rollback-file, via global.json or --version (for workload set versions, not individual manifests), --from-history (still under review, so not yet), or in the install state (which you aren't supposed to be hand-editing. Any vanilla command will just grab the latest, which is 8.0.2, I guess. |
I'll open a PR tomorrow 👍
You can see the whole adventure here 😅: https://github.com/martincostello/api/pull/1841/commits
|
|
|
hey @martincostello - can you try setting the DOTNET_INSTALL_DIR env var in your build scripts to see if ensuring an isolated environment sidesteps the issue? |
|
Sure - I'll try that out tomorrow. |
To add on to what Chet said here, because the base image included an Admin-installed SDK and the install scripts installed a file-based install to the same location, our theory is that there is some incompatibility there. We're also exploring this config ourselves to try to confirm as we may need the install actions to default to an isolated environment in the future. |
|
Is this what you had in mind? If so, it didn't work. |
|
Looks like Simplified workaround: +- name: Set DOTNET_INSTALL_DIR
+ if: runner.os == 'Windows'
+ shell: pwsh
+ run: |
+ "DOTNET_INSTALL_DIR=${env:GITHUB_WORKSPACE}\.dotnet" >> ${env:GITHUB_ENV}
- name: Setup .NET SDK
uses: actions/setup-dotnet@v4
+ env:
+ DOTNET_INSTALL_DIR: ${{ env.DOTNET_INSTALL_DIR }} |
|
Sorry I didn't get back to you too fast, but I put in a fix that I think will fix this. Can you check to see if (current main) works? |
|
Sure I can take a look - what was the change? |
|
Seems to be fixed (see martincostello/alexa-london-travel-site#2666), although there is a warning emitted during workload restore on Windows which I don't see using preview.7 nightlies where I'm using the workaround: Warning: Workload garbage collection failed with error: Workload manifest microsoft.net.sdk.aspire: 8.1.0/8.0.100 from workload version 9.0.100-rc.1.24381.10 was not installed. Running "dotnet workload repair" may resolve this..There's a different warning on Linux and macOS: Warning: Workload garbage collection failed with error: Workload pack 'Microsoft.NET.Runtime.Emscripten.Node.net8' in manifest 'microsoft.net.workload.emscripten.net8' [/Users/runner/.dotnet/sdk-manifests/9.0.100-rc.1/microsoft.net.workload.emscripten.net8/9.0.0-rc.1.24373.3/WorkloadManifest.json] conflicts with manifest 'microsoft.net.workload.emscripten.current' [/Users/runner/.dotnet/sdk-manifests/8.0.100/microsoft.net.workload.emscripten.current/8.0.7/WorkloadManifest.json]. |
|
#42315 was the change that I thought would resolve the error you were seeing. It basically says that if you don't specifically request workload sets, don't treat it like your baseline workload set missing a manifest is a problem. Interestingly, the symptom you're now seeing is very similar to another bug I'd fixed recently, but it has a different root cause. The baseline workload set was in the 8.0.100 folder (hardcoded), regardless of the SDK's real feature band. I fixed that, but I don't think that's the issue with this warning. The warning you're seeing is because the aspire manifest it expects really isn't installed. I suspect that if you were to run Aspire still isn't installing properly, and I don't have a perfect answer on that still. We did see that it's trying to install the SDK into a directory that already has an SDK installed by VS with the 8.0.0 version of aspire, which is generally not good, but I don't know how to resolve that, unfortunately, and it's a bit outside my area of expertise. |
|
This seems to be resolved with the official .NET 9 preview.7 release, as well as in the rc.1 nightlies. |
|
I am not sure if this is the same problem, but since a day I've am not able to build on our build agent. PowerShell Desktop version 5.1.14393.6343 Does it look like connected with this issue, or just a mess in our infrastructure? |
Describe the bug
Somewhere between
9.0.100-preview.7.24365.2and9.0.100-preview.7.24365.10(diff) of the .NET SDK, something has started to causedotnet workload restoreanddotnet buildto fail with the following exception on Windows (but not on Linux or macOS):I can repro this as recently as
9.0.100-preview.7.24367.5:dotnet workload restoredotnet buildLooking at the diff, the culprits could be either #41562 or #39991.
To Reproduce
build.ps1in the root of the repositoryThe text was updated successfully, but these errors were encountered: