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'

[sergiiPu]

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)

[parkerbo]

Experiencing this as well

[thatnerdyguy]

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 https://github.com/dotnet/runtime/issues/91932 which isn't our report, but lines up with what we are seeing today.

[eXeShnik]

Same here

[TanyaRandstoft]

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]

Fixed on 8.0.204 new sdk Just use and it will work

[StudioLE]

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: https://github.com/dotnet/aspnetcore/issues/55032#issuecomment-2045861572

It's possibly related to https://github.com/dotnet/sdk/issues/23820, however, that states "temporary failures" whereas for me it resulted in a significant corruption with no clear resolution.

[baronfel]

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.

[manishankar-ghosh]

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