dotnet-core/release-notes/5.0/5.0-known-issues.md
2020-11-10 08:11:58 -08:00

139 lines
8.5 KiB
Markdown

# .NET 5 Known Issues
This document lists known issues for **.NET 5** which may be encountered during usage.
## .NET Runtime
## GA
1. When reading from a NegotiateStream at EOF, the stream will throw rather than return 0 or -1. This will be fixed in 5.0.1. It is tracked by [dotnet/runtime/pr #43741](https://github.com/dotnet/runtime/pull/43741).
## ASP.NET Core Runtime
### RC1
#### Authentication using Identity Server does not work when applications are published as single file applications
*Problem:*
Applications that use Identity Server 4 will throw exceptions when published as a single file application. This includes applications generated from Blazor templates which include authentication for in-application, individual accounts.
*Workaround:*
Do not publish applications which include Identity Server as single file applications.
#### TcpListener throwing `SocketException` instead of `ObjectDisposedException`
*Problem:*
When calling `Stop` after `BeginAcceptSocket` or `BeginAcceptTcpClient` on a `TcpListener` instance, a subsequent `EndAcceptSocket` or `EndAcceptTcpClient` call will throw `SocketException` with `SocketError.OperationAborted` (995) instead of `ObjectDisposedException`:
https://github.com/dotnet/runtime/issues/41585
*Workaround:*
If you're using [APM](https://docs.microsoft.com/dotnet/standard/asynchronous-programming-patterns/asynchronous-programming-model-apm) Accept metods on `TcpClient`, change the catch block (temporarily), when updating to RC1:
```diff
try
{
Socket client = listener.EndAcceptSocket(ar);
}
catch (ObjectDisposedException ex)
{
// Original exception handler -- won't be invoked in RC1
HandleListenerStopped(listener);
}
+catch (SocketException ex) when (ex.SocketErrorCode == SocketError.OperationAborted)
+{
+ // This handler will be hit in RC1, but not in subsequent releases,
+ // so it could be removed starting from RC2.
+ HandleListenerStopped(listener);
+}
```
#### Blazor Virtualization component limitations
Issues resolved in 5.0 RC2 by https://github.com/dotnet/aspnetcore/pull/25260.
The Virtualization component is new in RC1 and there are some fixes we didn't fit in RC1, which make the component unusable for certain scenarios.
1. Item size calculations can be wrong by a subpixel amount, which accumulates and produces offsets in scrolling when the source list goes beyond several pages.
2. When items don't have @key, scrolling can get stuck in a loop.
## .NET SDK
### RC1
1. Libraries targeting net5-windows that were compiled with preview 8 will need to be recompiled. This is because they have an assembly-level `MinimumOSPlatformAttribute` defined, which was renamed to `SupportedOSPlatformAttribute` in RC1. Reflecting over the assembly with the old attribute can fail. For WPF projects, this can surface as a failure in the MarkupCompilePass1 target:
> C:\Program Files\dotnet\sdk\5.0.100-rc.1.20453.4\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(240,9): error MC1000: Unknown build error, 'Could not find type 'System.Runtime.Versioning.MinimumOSPlatformAttribute' in assembly 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\5.0.0-rc.1.20452.14\ref\net5.0\System.Runtime.dll'.'
- MinimumOSPlatformAttribute was renamed to SupportedOSPlatformAttribute
- RemovedInOSPlatformAttribute was renamed to UnsupportedOSPlatformAttribute
- ObsoletedInOSPlatformAttribute was removed.
2. Resolved -- Warning icons in Dependencies node in Solution Explorer
- For projects targeting .NET 5 where there's a package downgrade error, warning icons won't be displayed on the error message's ancestor nodes (such as the package node, the "Packages" node, and the "Dependencies" node) in the Solution Explorer
3. Resolved -- Restore of F# project with TargetFramework*s* and /p:RestoreUseStaticGraphEvaluation=true will fail with NuGet.RestoreEx.targets(10,5): error : Invalid restore input. Invalid target framework 'unsupported'.
- Workaround: Add the following block to your fsproj file:
```xml
<PropertyGroup>
<InnerBuildProperty>TargetFramework</InnerBuildProperty>
<InnerBuildPropertyValues>TargetFrameworks</InnerBuildPropertyValues>
</PropertyGroup>
```
4. Resolved -- When launching Blazor apps from VS or initializing a debugging session in the browser, port 9300 must be open on the machine the Blazor app is running under.
### RC2
1. For Windows Application Packaging projects targeting net5.0, we recommend targeting the Windows SDK 19041. This Windows SDK is not installed by default in the Visual Studio installer options though is available and an Optional component.
- You might see build error `APPX3217`: `SDK folder containing 'UAP.props' for 'UAP 10.0.19041.0' could not be located.`
2. Dotnet tool pack does not support the new net5.0 framework alias. Please continue to target netcoreapp3.1 for now for WPF or Winforms dotnet tools. See https://github.com/dotnet/sdk/pull/13924
2. Resolved -- Dotnet tool pack does not support the new net5.0 framework alias. Please continue to target netcoreapp3.1 for now for WPF or Winforms dotnet tools. See https://github.com/dotnet/sdk/pull/13924
3. Resolved -- Publishing with ReadyToRunUseCrossgen2 fails with an `An assembly specified in the application dependencies manifest (crossgen2.deps.json) was not found` error.
### GA
1. New Angular templates created via the `dotnet new` CLI or the new project UI in VS may fail to build on the command line due to an issue with the `node-gyp` install. To workaround this issue, upgrade the version of the `node-sass` dependency in `ClientApp/package.json` to `5.0.0`.
2. When creating a new **C# desktop** application in Visual Studio 2019 version 16.8 (including Console App, Windows Forms App, or WPF App), the project will default to targeting the latest LTS SDK that is installed (e.g. .NET Core 3.1). To create a new .NET 5 project, you can either use the CLI, or create a new project in Visual Studio and immediately retarget to .NET 5 in the project properties. When you retarget from 3.1 to .NET 5.0, it is no longer necessary to append .WindowsDestkop to the SDK reference. Consider changing **Microsoft.NET.Sdk.WindowsDesktop** to just **Microsoft.NET.Sdk**. You can also modify this behavior by enabling the Visual Studio preview feature: "Show all .NET Core templates in the New Project dialog".
3. Design time build failure and dependency node warning icons when targeting *netcoreapp2.1* and specifying a *RuntimeIdentifier* in the project file. This is the default for Service Fabric projects.
**Error experience**
`Project is targeting runtime 'win7-x64' but did not resolve any runtime-specific packages for the 'Microsoft.NETCore.App' package. This runtime may not be supported by .NET Core.`
**Workaround**
Add a *Directory.Build.Targets* file with the following content
```xml
<Project>
<Target Name="EnsureNETCoreAppRuntime" />
</Project>
```
4. dotnet new -i for a template uses NuGet restore to download the template package and this requires a `TargetFramework`. The template engine defaults to `netcoreapp1.0` to restore the template. This will trigger warning NETSDK1138 as that target framework is no longer supported but has no negative affect on the template download.
## MSBuild
### RC2
In .NET 5.0 preview 7 through RC1, projects that target net5.0 define both NETCOREAPP3_1 and NET5_0 preprocessor symbols. The intent behind this behavior change was that starting with .NET 5.0, conditional compilation [symbols would be cumulative](https://github.com/dotnet/designs/blob/main/accepted/2020/net5/net5.md#preprocessor-symbols).
In .NET 5.0 RC2 and later, projects only define symbols for the target framework monikers (TFM) that it targets and not for any earlier versions.
Visit [MSBuild breaking change](https://docs.microsoft.com/dotnet/core/compatibility/msbuild#netcoreapp3_1-preprocessor-symbol-is-not-defined-when-targeting-net-5) for more details.
## Windows Forms
### RC1
* Changes at runtime to an instance of an `ImageList` which is already bound to a control (such as a `ListView` or a `TreeView`) won't be reflected in the control until the instance of the `ImageList` is re-assigned to the said control.
- Workaround: after changes to an instance of a `ImageList` unbind it from a control, and bind back:
```cs
imageList.Images.Add(image);
listView1.LargeImageList = null; // unbind
listView1.LargeImageList = imageList; // bind back
```
The issue is expected to be fixed in 5.0.1.