Skip to content
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

Unhandled exception: Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Workload manifest dependency 'Microsoft.NET.Workload.Emscripten.Current' version '8.0.3' is lower than version '8.0.4' required by manifest 'microsoft.net.workload.mono.toolchain.current' #40070

Open
sergiiPu opened this issue Apr 9, 2024 · 8 comments
Assignees
Milestone

Comments

@sergiiPu
Copy link

sergiiPu commented Apr 9, 2024

Describe the bug

dotnet workload install command can not be performed after release of "Microsoft.NET.Workload.Mono.ToolChain.Current.Manifest-8.0.100" Version="8.0.4"

To Reproduce

run dotnet worload install

Exceptions (if any)

Unhandled exception: Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Workload manifest dependency 'Microsoft.NET.Workload.Emscripten.Current' version '8.0.3' is lower than version '8.0.4' required by manifest 'microsoft.net.workload.mono.toolchain.current' [/azp/agent/_work/_tool/dotnet/sdk-manifests/8.0.100/microsoft.net.workload.mono.toolchain.current/8.0.4/WorkloadManifest.json]
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.ComposeWorkloadManifests()
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.Create(IWorkloadManifestProvider manifestProvider, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadResolverFactory.Create(String globalJsonStartDir)
at Microsoft.DotNet.Workloads.Workload.InstallingWorkloadCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadInstallCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath, IReadOnlyCollection`1 workloadIds)
at Microsoft.DotNet.Cli.WorkloadInstallCommandParser.<>c.b__6_0(ParseResult parseResult)
at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)

@dotnet-issue-labeler dotnet-issue-labeler bot added Area-Workloads untriaged Request triage from a team member labels Apr 9, 2024
@parkerbo
Copy link

parkerbo commented Apr 9, 2024

Experiencing this as well

@thatnerdyguy
Copy link

Also experiencing this. Last time we thought we "fixed" it by updated VS across all the build machines. But that doesn't seem to help now.

See also dotnet/runtime#91932 which isn't our report, but lines up with what we are seeing today.

@eXeShnik
Copy link

eXeShnik commented Apr 9, 2024

Same here

@TanyaRandstoft
Copy link

TanyaRandstoft commented Apr 9, 2024

Same here, on Arm64 based MacOS Sonoma 14.4.1
Started out earlier today in Linux based machine, that seems to have been fixed, but still not working on Arm Mac

Unhandled exception: Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Workload manifest dependency 'Microsoft.NET.Workload.Emscripten.Current' version '8.0.3' is lower than version '8.0.4' required by manifest 'microsoft.net.workload.mono.toolchain.current' [/usr/local/share/dotnet/sdk-manifests/8.0.100/microsoft.net.workload.mono.toolchain.current/8.0.4/WorkloadManifest.json]
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.ComposeWorkloadManifests()
at Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadResolver.Create(IWorkloadManifestProvider manifestProvider, String dotnetRootPath, String sdkVersion, String userProfileDir)
at Microsoft.DotNet.Workloads.Workload.Install.WorkloadResolverFactory.Create(String globalJsonStartDir)
at Microsoft.DotNet.Workloads.Workload.InstallingWorkloadCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath)
at Microsoft.DotNet.Workloads.Workload.Update.WorkloadUpdateCommand..ctor(ParseResult parseResult, IReporter reporter, IWorkloadResolverFactory workloadResolverFactory, IInstaller workloadInstaller, INuGetPackageDownloader nugetPackageDownloader, IWorkloadManifestUpdater workloadManifestUpdater, String tempDirPath)
at Microsoft.DotNet.Cli.WorkloadUpdateCommandParser.<>c.b__6_0(ParseResult parseResult)
at System.CommandLine.Invocation.InvocationPipeline.Invoke(ParseResult parseResult)
at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)

@eXeShnik
Copy link

eXeShnik commented Apr 9, 2024

Fixed on 8.0.204 new sdk
Just use and it will work

@StudioLE
Copy link

I also experienced this when running dotnet workload install wasm-tools while 8.0.4 was part way through being released yesterday.

It resulted in a corrupted state of dotnet on my linux machine which broke most dotnet commands. I was able to resolve it with the following rather hacky steps: dotnet/aspnetcore#55032 (comment)

It's possibly related to #23820, however, that states "temporary failures" whereas for me it resulted in a significant corruption with no clear resolution.

@baronfel
Copy link
Member

We have automation that verifies that the various workload packages are available on NuGet.org, but we didn't enforce the ordering of emscripten and the rest of the manifest packages - we're going to try and update our automation/processes to enforce this ordering, so this should go away in the future.

Looking even further ahead, when we release workload sets that feature by design should never have this kind of ordering problem because the workload set information is a natural 'gate' on the package uploads.

@marcpopMSFT marcpopMSFT added this to the Discussion milestone Apr 26, 2024
@marcpopMSFT marcpopMSFT removed the untriaged Request triage from a team member label Apr 26, 2024
@manishankar-ghosh
Copy link

I was facing the same problem but with .net 8. Installing the latest .net sdk from the below location fixed it for me:
https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/sdk-8.0.302-windows-x64-installer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants