SDK Resolver Failure - Net 7 - Net 6

Just downloaded and installed SDK Net 7.0.100 and it broke existing applications and they won't load any more in VS 2022 or Rider.

Copied the follwing error:

error  : SDK Resolver Failure: "The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" 
failed while attempting to resolve the SDK "Microsoft.NET.Sdk". Exception: "Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadManifestCompositionException: Workload definition 'wasm-tools' in manifest 'microsoft.net.workload.mono.toolchain.net7' [C:\Program Files\dotnet\sdk-manifests\7.0.100\microsoft.net.workload.mono.toolchain.net7\WorkloadManifest.json] conflicts with manifest 'microsoft.net.workload.mono.toolchain' [C:\Program Files\dotnet\sdk-manifests\7.0.100\microsoft.net.workload.mono.toolchain\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.NET.Sdk.WorkloadMSBuildSdkResolver.CachingWorkloadResolver.Resolve(String sdkReferenceName, String dotnetRootPath, String sdkVersion, String userProfileDir)
   at Microsoft.DotNet.MSBuildSdkResolver.DotNetMSBuildSdkResolver.Resolve(SdkReference sdkReference, SdkResolverContext context, SdkResultFactory factory)
   at Microsoft.Build.BackEnd.SdkResolution.SdkResolverService.TryResolveSdkUsingSpecifiedResolvers(IList`1 resolvers, Int32 submissionId, SdkReference 

I experienced a similar problem. I uninstalled the 7.0.100-preview.5.22307.18 sdk using add remove programs and then changed the TargetFramework in the project file to use 7.0 and then I was able to load the projects.

I experienced a similar problem. I uninstalled the 7.0.100-preview.5.22307.18 sdk using add remove programs and then changed the TargetFramework in the project file to use 7.0 and then I was able to load the projects.

EDIT: This is officially documented in the release notes known issues.

I'm from the .NET SDK team. Sorry you're going through this. I would love to comment on the other answers, but I don't have the reputation to do so.

What Tim Farley suggested is an officially endorsed workaround; uninstalling any preview 7 SDKs with add/remove programs should resolve the problem. As for why this happened and why uninstalling preview SDKs will fix the issue, there's a bit of an explanation I put here: https://github.com/dotnet/sdk/issues/28947#issuecomment-1307987337. TLDR: Some workloads were renamed in the middle of .NET 7 preview development to support things like multitargeting, and when you download the new RTM old preview files interfere can with it.

Updating the TargetFramework is recommended but it's unrelated to this issue. Usually breaking changes for each .NET version and related new features are gated behind your TargetFramework (TFM), so things don't break until you update the TFM, not when you update the SDK. (Unfortunately, not true in this case.)

In response to whether this will happen again or not when upgrading to .NET 8, per Scott: with how workloads are currently structured this issue would happen again. We're discussing how to make changes to prevent this from happening again though as it's not ideal. We're also considering adding dotnet workload clean or something to repair this for you. Communicating with us on the SDK GH thread, or with me here, is a good way to send us feedback about this.

EDIT: This is officially documented in the release notes known issues.

I'm from the .NET SDK team. Sorry you're going through this. I would love to comment on the other answers, but I don't have the reputation to do so.

What Tim Farley suggested is an officially endorsed workaround; uninstalling any preview 7 SDKs with add/remove programs should resolve the problem. As for why this happened and why uninstalling preview SDKs will fix the issue, there's a bit of an explanation I put here: https://github.com/dotnet/sdk/issues/28947#issuecomment-1307987337. TLDR: Some workloads were renamed in the middle of .NET 7 preview development to support things like multitargeting, and when you download the new RTM old preview files interfere can with it.

Updating the TargetFramework is recommended but it's unrelated to this issue. Usually breaking changes for each .NET version and related new features are gated behind your TargetFramework (TFM), so things don't break until you update the TFM, not when you update the SDK. (Unfortunately, not true in this case.)

In response to whether this will happen again or not when upgrading to .NET 8, per Scott: with how workloads are currently structured this issue would happen again. We're discussing how to make changes to prevent this from happening again though as it's not ideal. We're also considering adding dotnet workload clean or something to repair this for you. Communicating with us on the SDK GH thread, or with me here, is a good way to send us feedback about this.