You may encounter the following known issues, which may include workarounds, mitigations or expected resolution timeframes.
Installing MSI based optional workloads using the CLI will result in a PlatformNotSupported exception on Windows (arm64). The CLI installer has a dependency on System.Management that is not support on Windows (arm64). This dependency has been removed in RC2.
There is no workaround for this issue in RC1, except to switch to the file based workload installation.
These files are only needed during builds and cause confusion for customers to see extra binaries built to the bin\ref folder. Instead they were moved to only build to the obj/ref folder.
Note, this change is being reverted for RC1 as we found a hardcoded path in Roslyn in VS scenarios that has to be addressed first
The workload names all changed between preview 6 and 7 so the SDK doesn't recognize how to clean up existing installed workloads from earlier previews and will error
Garbage collecting for SDK feature bands 6.0.100... Workload installation failed: Workload not found: microsoft-net-sdk-blazorwebassembly-aot. Known workloads: ...
Another potential error
Garbage collecting for SDK feature bands 6.0.100… Workload installation failed: The JSON value could not be converted to Microsoft.NET.Sdk.WorkloadManifestReader.WorkloadPackId. Path: $.Id | LineNumber: 0 | BytePositionInLine: 40.
Workaround Delete your dotnet\metadata folder and try the workload install again. The metadata folder contains our records of what workloads you've tried to install and is what's triggering us to try to clean up an older workload that may not be recognized or compatible with the current SDK.
Note that a side effect of this is that the SDK will leave behind some older preview workloads across various packs directories.
dotnet workload install will error with workload not found when using the .NET SDK CLI installed with Visual Studio preview 1. To work around this, please install the stand-alone SDK of preview 5 on the same machine.
2. Upgrades from .NET SDK Preview 4 to Preview 5 leave tools in a broken state. Projects will fail to load in Visual Studio, and many SDK commands will fail, such as creating, building, or restoring a project.
This can manifest in several different ways. For example, when using the dotnet CLI, you may get an error similar to the following:
dotnet new console
An item with the same key has already been added. Key: microsoft-android-sdk-full
at System.Collections.Generic.Dictionary`2.TryInsert(TKey key, TValue value, InsertionBehavior behavior) in
When opening a project in Visual Studio, you may get an error similar to the following:
The project file cannot be opened. The NuGet-based SDK resolver failed to run because NuGet assemblies could not be located. Check your installation of MSBuild or set the environment variable “MSBUILD_NUGET_PATH” to the folder that contains the required NuGet assemblies. Could not find file ‘C:\Program Files\dotnet\sdk-manifests\6.0.100\Microsoft.NET.Workload.Android\WorkloadManifest.json’.
When opening a project in Visual Studio for Mac, you may get an error similar to the following:
Unable to find SDK
'Microsoft.NET.SDK.WorkloadAutoImportPropsLocator'
SDK not found
The issue is caused because we renamed SDK workload manifests between preview 4 and preview 5. If both versions of the manifests are installed, they will conflict with each other, leading to the "An item with the same key has already been added" error.
Errors that a WorkloadManifest.json file could not be found may be caused if the maui-check tool had previously been run with Preview 4. The tool would add some additional files to the workload manifest folders, which prevents the folders from being deleted when installing Preview 5. These manifest folders without a WorkloadManfiest.json file then cause the file not found error.
Workaround
In the .NET SDK installation folder, delete all folders under sdk-manifests\6.0.100 (for example, under C:\Program Files\dotnet\sdk-manifests\6.0.100) that have the form Microsoft.NET.Workload.*, EXCEPT for microsoft.net.workload.mono.toolchain
Or
If you want to use .NET MAUI, you can run the latest version of the maui-check tool. This will delete the outdated manifest folders and set up your environment for .NET MAUI development.
The .NET SDK Optional Workloads were renamed between preview 4 and preview 5 and are not compatible. As such, the dotnet workload update command won't work for a preview 4 installed workload but should work with preview 5 and onward.
- Workload install for protected install location (eg. c:\program files) will fail
In the future, the .NET SDK will trigger elevation to install missing workloads but today that fails.
C:\Users\MPP>dotnet workload install microsoft-macos-sdk-full --skip-manifest-update
Installing pack Microsoft.macOS.Sdk version 11.3.100-preview.5.889...
Workload installation failed, rolling back installed packs...
Rolling back pack Microsoft.macOS.Sdk installation...
Workload installation failed: One or more errors occurred. (Access to the path 'C:\Program Files\dotnet\metadata\temp\microsoft.macos.sdk\11.3.100-preview.5.889' is denied.)
Workaround You'll need to elevate your command prompt before running the install command.
There is an incompatibility between .NET MAUI tooling features and Windows App SDK that prevents apps from launching and debugging. You can work around this by building and deploying without debugging, and then launching the application from the Start menu and attaching the debugger. A fix is underway and will come in a future Visual Studio 2022 service release.
- Issue in "dnSpy.exe" fpr .NET 6.0 Preview 5 as described in dotnet/runtime #53014
A fix for this issue will be available in .NET 6.0 Prevew 6
- Issue in
ReadyToRunfeature for .NET Preview 6.0 Preview 3 as described in dotnet/runtime #50472
Workaround
You can workaround this issue by setting COMPlus_ReadyToRun=0 environment variable.
- Microsoft.Extensions.DependencyInjection .NET 6.0 Preview 5 has a regression related to injecting more than 5 services into an IEnumerable<T>, see dotnet/runtime #54407 for more details.
Workaround
If using the generic host, you can disable the ValidateOnBuild option:
Host.CreateDefaultBuilder(args)
.UseDefaultServiceProvider(o =>
{
o.ValidateOnBuild = false;
});If using the BuildServiceProvider container directly, ValidateOnBuild is not on by default.
-
PropertyGridvalues are rendered at incorrect location.The issue is tracked in dotnet/winforms#4593 and is expected to be fixed in 6.0 Preview3.
Running Blazor WebAssembly using IIS Express in Development
As of .NET 6 Preview 1, there is an ongoing issue with running Blazor WebAssembly applications using an IIS Express server during development on Visual Studio. As a workaround, we recommend using Kestrel during development.
Incremental builds in VS not working for apps with Razor views
As of .NET 6 Preview 3, changes to Razor views will not be updated during incremental builds. As a workaround, you can:
- Build from the command line
- Configure VS to always call MSBuild when building projects
- Clean and build projects to pick up changes
JWT Bearer Handler ArgumentOutOfRangeException in UTC+X time zones
As of .NET 6 Preview 5, when using the JWT Bearer handler in a time zone that is higher than UTC (e.g. Eastern European Time/UTC+2), you may observe an ArgumentOutOfRangeException if the JWT token does not contain a nbf value (valid from).
Issue is tracked by dotnet/aspnetcore#33634 and will be fixed in .NET 6 Preview 6.
Workaround
You can workaround this by always providing a non-zero and non-minimum value for the notBefore parameter when using System.IdentityModel.Tokens.Jwt.JwtSecurityToken, or the 'nbf' field if using another JWT library.