dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI
https://dot.net/core
MIT License
2.71k stars 1.06k forks source link

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 6 months ago

sergiiPu commented 6 months ago

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 commented 6 months ago

Experiencing this as well

thatnerdyguy commented 6 months ago

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 commented 6 months ago

Same here

TanyaRandstoft commented 6 months ago

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 commented 6 months ago

Fixed on 8.0.204 new sdk Just use and it will work

StudioLE commented 6 months ago

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 commented 6 months ago

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 commented 3 months ago

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