maxmustermann/dotnet-core
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Merge pull request #6796 from dotnet/rbhanda-patch-2

Browse source 
Update known-issues.md
This commit is contained in:
Rahul Bhandari 2021-10-12 10:55:05 -07:00 committed by GitHub
parent b2d5de2c02 9e6084064f
commit 52052bbb89
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 103 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

107
release-notes/6.0/known-issues.md
View file

@ -1,4 +1,4 @@
# .NET 6.0 Known Issues
# .NET 6.0 RC1 Known Issues
You may encounter the following known issues, which may include workarounds, mitigations or expected resolution timeframes.
@ -11,79 +11,19 @@ If you build .NET 6 projects with MSBuild 16.11, for example, you will see the f
`warning NETSDK1182: Targeting .NET 6.0 in Visual Studio 2019 is not supported`
### RC 1
#### 1. Optional workloads on Windows (arm64)
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.
### Preview 7
#### 1. Reference assemblies no longer output to the bin directory
#### 2. Reference assemblies no longer output to the bin directory
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](https://github.com/dotnet/msbuild/pull/6560) to only build to the obj/ref folder.
**Note, this change is being [reverted](https://github.com/dotnet/msbuild/pull/6718) for RC1 as we found a hardcoded path in Roslyn in VS scenarios that has to be addressed first**
#### 2. Error when cleaning up preview 6 workloads when installing preview 7 workloads
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.
### Preview 5
#### 1. Missing Workload Manifests in Visual Studio 17 Preview 1
`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](https://github.com/Redth/dotnet-maui-check/blob/main/README.md). This will delete the outdated manifest folders and set up your environment for .NET MAUI development.
#### 3. Workload update from preview 4 not working
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.
### Preview 4
1. Workload install for protected install location (eg. c:\program files) will fail
#### 3. 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.
@ -97,46 +37,7 @@ Workload installation failed: One or more errors occurred. (Access to the path '
```
**Workaround**
You'll need to elevate your command prompt before running the install command.
#### 3. .NET MAUI Windows apps fail to debug in Visual Studio 2022 Preview 3
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.
## .NET Runtime
1. Issue in "dnSpy.exe" fpr .NET 6.0 Preview 5 as described in [dotnet/runtime #53014](https://github.com/dotnet/runtime/issues/53014)
A [fix](https://github.com/dotnet/runtime/pull/53574) for this issue will be available in .NET 6.0 Prevew 6
2. Issue in `ReadyToRun` feature for .NET Preview 6.0 Preview 3 as described in [dotnet/runtime #50472](https://github.com/dotnet/runtime/issues/50472)
**Workaround**
You can workaround this issue by setting `COMPlus_ReadyToRun=0` environment variable.
3. **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](https://github.com/dotnet/runtime/issues/54407) for more details.
**Workaround**
If using the generic host, you can disable the `ValidateOnBuild` option:
```C#
Host.CreateDefaultBuilder(args)
.UseDefaultServiceProvider(o =>
{
o.ValidateOnBuild = false;
});
```
If using the `BuildServiceProvider` container directly, `ValidateOnBuild` is not on by default.
## Windows Forms
* `PropertyGrid` values are rendered at incorrect location.
The issue is tracked in [dotnet/winforms#4593](https://github.com/dotnet/winforms/issues/4593) and is expected to be fixed in 6.0 Preview3.
## ASP.NET Core
### Running Blazor WebAssembly using IIS Express in Development