3.0 known issues refactoring (#3461)
This commit is contained in:
Vivek Mishra
GitHub
parent
d15fb9963a
commit
74c8d46d83
63
release-notes/3.0/3.0-known-issues.md
Normal file
63
release-notes/3.0/3.0-known-issues.md
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
# .NET Core 3.0 Known Issues
|
||||
|
||||
This document lists known issues for **.NET Core 3.0 GA and beyond releases** which may be encountered during usage.
|
||||
|
||||
## .NET Core
|
||||
|
||||
### .NET Core 3.0 SDK, all releases
|
||||
|
||||
- **`PATH` intermittently not updated when installing on MacOS ([core-sdk/3331](https://github.com/dotnet/core-sdk/issues/3331))**
|
||||
|
||||
There are some situations, which we do not yet understand, where PATH is not properly updated after installing the .NET Core SDK on MacOS. The result is a `dotnet: command not found` error reported in the terminal when attempting to run a `dotnet` command.
|
||||
|
||||
The PATH issue can be confirmed by typing `echo $PATH | grep "dotnet"` and observing if `dotnet` is shown in the output. If `/usr/local/share/dotnet` is not present in PATH, it can be added for the current terminal session with `export PATH = $PATH:/usr/local/share/dotnet`.
|
||||
|
||||
To update the path for every new terminal session, the `export` entry will need to be added to your terminal resource file. This file will be different depending upon your default terminal (eg bash, zsh, ...) and configuration (.bash_profile, .bashrc, .zshrc, ...).
|
||||
|
||||
### Preview 9
|
||||
|
||||
- **Misnamed or colliding non-resx resources ([microsoft/msbuild#4740](https://github.com/microsoft/msbuild/issues/4740))**
|
||||
|
||||
Projects that specify non-resx `EmbeddedResource`s may have the resources embedded under an incorrect name (causing code that uses the correct name to fail at runtime). If two or more files are embedded in this way, `CS1508: The resource identifier ... has already been used in this assembly` may be issued at build time.
|
||||
|
||||
This can be worked around with a property in the project file
|
||||
|
||||
```xml
|
||||
<PropertyGroup>
|
||||
<!-- Work around https://github.com/microsoft/msbuild/issues/4740 -->
|
||||
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
|
||||
</PropertyGroup>
|
||||
```
|
||||
|
||||
- **Builds fail with `MSB3041` when a `.resx` file is in a subfolder [microsoft/msbuild#4695](https://github.com/microsoft/msbuild/issues/4695)**
|
||||
|
||||
MSBuild incorrectly constructs paths to `DependentUpon` source files related to `.resx` files that aren't at the project root. There is a workaround:
|
||||
|
||||
Explicitly set `DependentUpon` metadata for resource files ([example for Entity Framework migrations](https://github.com/aspnet/EntityFramework6/issues/1225#issuecomment-528571274)).
|
||||
|
||||
### Preview 5
|
||||
|
||||
- **Visual style in WinForms app not showing correctly when publishing with PublishReadyToRun=true**
|
||||
|
||||
The ReadyToRun compiler in this preview does not copy Win32 resources from the managed assembly to the compiled output binary, which causes an issue with visual styles in WinForms apps. The workaround is to skip compilation of System.Windows.Forms.dll by adding the following to the project file:
|
||||
```xml
|
||||
<ItemGroup>
|
||||
<PublishReadyToRunExclude Include="System.Windows.Forms.dll" />
|
||||
</ItemGroup>
|
||||
```
|
||||
|
||||
## ASP.NET Core
|
||||
|
||||
### 3.0.0 GA
|
||||
|
||||
- **gRPC runtime files may not be deployed on publish**
|
||||
|
||||
It is possible that some gRPC runtime files (PDBs) will not be deployed when publishing your application.
|
||||
|
||||
This can be fixed by updating your package reference to `Grpc.AspNetCore` to `2.23.2` (or greater) in the project file:
|
||||
|
||||
```xml
|
||||
<ItemGroup>
|
||||
<PackageReference Include="Grpc.AspNetCore" Version="2.23.2" />
|
||||
</ItemGroup>
|
||||
```
|
||||
|
|
@ -5,7 +5,7 @@
|
|||
**Visual Studio compatibility:** .NET Core 3.0.0 requires Visual Studio 2019 16.3 GA to take full advantage of all its features. .NET Core 3.0.0 will not work properly in earlier versions of Visual Studio.
|
||||
|
||||
* [Changes in this release](#notable-changes-in-300)
|
||||
* [Known issues](https://github.com/dotnet/core/blob/master/release-notes/3.0/preview/3.0.0-preview-known-issues.md)
|
||||
* [Known issues](../3.0-known-issues.md)
|
||||
* [Downloads](https://dotnet.microsoft.com/download/dotnet-core/3.0)
|
||||
|
||||
The .NET Core SDK 3.0.100 includes .NET Core 3.0 Runtime so downloading the runtime packages separately is not needed when installing the SDK. After installing the .NET Core SDK 3.0.100, the following command will show that you're running version `3.0.100` of the tools.
|
||||
|
|
|
|||
|
|
@ -1,27 +1,43 @@
|
|||
# .NET Core 3.0 Known Issues
|
||||
|
||||
This document lists known issues for **.NET Core 3.0 GA and Preview releases** which may be encountered during usage.
|
||||
***Note: For all new known issues after [3.0 GA](../3.0.0/3.0.0.md) refer the [3.0 known issues file.](../3.0-known-issues.md)***
|
||||
|
||||
# .NET Core 3.0 Preview Known Issues
|
||||
|
||||
This document lists known issues for **.NET Core 3.0 Preview releases** which may be encountered during usage.
|
||||
|
||||
## .NET Core
|
||||
|
||||
### .NET Core 3.0 SDK, all releases
|
||||
|
||||
### `PATH` intermittently not updated when installing on MacOS ([core-sdk/3331](https://github.com/dotnet/core-sdk/issues/3331))
|
||||
- **`PATH` intermittently not updated when installing on MacOS ([core-sdk/3331](https://github.com/dotnet/core-sdk/issues/3331))**
|
||||
|
||||
There are some situations, which we do not yet understand, where PATH is not properly updated after installing the .NET Core SDK on MacOS. The result is a `dotnet: command not found` error reported in the terminal when attempting to run a `dotnet` command.
|
||||
There are some situations, which we do not yet understand, where PATH is not properly updated after installing the .NET Core SDK on MacOS. The result is a `dotnet: command not found` error reported in the terminal when attempting to run a `dotnet` command.
|
||||
|
||||
The PATH issue can be confirmed by typing `echo $PATH | grep "dotnet"` and observing if `dotnet` is shown in the output. If `/usr/local/share/dotnet` is not present in PATH, it can be added for the current terminal session with `export PATH = $PATH:/usr/local/share/dotnet`.
|
||||
The PATH issue can be confirmed by typing `echo $PATH | grep "dotnet"` and observing if `dotnet` is shown in the output. If `/usr/local/share/dotnet` is not present in PATH, it can be added for the current terminal session with `export PATH = $PATH:/usr/local/share/dotnet`.
|
||||
|
||||
To update the path for every new terminal session, the `export` entry will need to be added to your terminal resource file. This file will be different depending upon your default terminal (eg bash, zsh, ...) and configuration (.bash_profile, .bashrc, .zshrc, ...).
|
||||
To update the path for every new terminal session, the `export` entry will need to be added to your terminal resource file. This file will be different depending upon your default terminal (eg bash, zsh, ...) and configuration (.bash_profile, .bashrc, .zshrc, ...).
|
||||
|
||||
### Preview 9
|
||||
|
||||
- **Misnamed or colliding non-resx resources ([microsoft/msbuild#4740](https://github.com/microsoft/msbuild/issues/4740))**
|
||||
|
||||
Projects that specify non-resx `EmbeddedResource`s may have the resources embedded under an incorrect name (causing code that uses the correct name to fail at runtime). If two or more files are embedded in this way, `CS1508: The resource identifier ... has already been used in this assembly` may be issued at build time.
|
||||
|
||||
This can be worked around with a property in the project file
|
||||
|
||||
```xml
|
||||
<PropertyGroup>
|
||||
<!-- Work around https://github.com/microsoft/msbuild/issues/4740 -->
|
||||
<EmbeddedResourceUseDependentUponConvention>false</EmbeddedResourceUseDependentUponConvention>
|
||||
</PropertyGroup>
|
||||
```
|
||||
|
||||
- **Builds fail with `MSB3041` when a `.resx` file is in a subfolder [microsoft/msbuild#4695](https://github.com/microsoft/msbuild/issues/4695)**
|
||||
|
||||
MSBuild incorrectly constructs paths to `DependentUpon` source files related to `.resx` files that aren't at the project root. There is a workaround:
|
||||
|
||||
Explicitly set `DependentUpon` metadata for resource files ([example for Entity Framework migrations](https://github.com/aspnet/EntityFramework6/issues/1225#issuecomment-528571274)).
|
||||
|
||||
|
||||
### Preview 5
|
||||
|
||||
- **Visual style in WinForms app not showing correctly when publishing with PublishReadyToRun=true**
|
||||
|
|
@ -33,7 +49,7 @@ To update the path for every new terminal session, the `export` entry will need
|
|||
</ItemGroup>
|
||||
```
|
||||
|
||||
- **Scaffolding hangs indefinitely**
|
||||
- **[RESOLVED] Scaffolding hangs indefinitely**
|
||||
|
||||
With a 3.0.100-preview5 SDK installed, and Visual Studio 16.0-preview2 or earlier, attempting to scaffold a .NET Core 3.0 project in Visual Studio will cause Visual Studio to hang indefinitely, with no indication of the problem. With a 3.0.100-preview5 SDK installed, and Visual Studio 16.0-preview3, Scaffolding will fail for all 3.0 projects.
|
||||
|
||||
|
|
@ -43,7 +59,7 @@ To update the path for every new terminal session, the `export` entry will need
|
|||
|
||||
### Preview 9
|
||||
|
||||
- **WebSocket connections to IIS In-Process servers will close after the client sends ~30MB**
|
||||
- **[RESOLVED] WebSocket connections to IIS In-Process servers will close after the client sends ~30MB**
|
||||
|
||||
WebSocket connections to IIS In-Process servers will close after the client sends ~30MB of data.
|
||||
|
||||
|
|
@ -62,25 +78,25 @@ To update the path for every new terminal session, the `export` entry will need
|
|||
|
||||
### Preview 8
|
||||
|
||||
- **Starting a client or bi-directional streaming gRPC call with an already canceled `CallOptions.CancellationToken` will hang**
|
||||
- **[RESOLVED] Starting a client or bi-directional streaming gRPC call with an already canceled `CallOptions.CancellationToken` will hang**
|
||||
|
||||
Starting a client or bi-directional streaming call with an already canceled `CallOptions.CancellationToken` will not properly cancel the call. Sending a message with `RequestStream.WriteAsync` will hang.
|
||||
|
||||
To workaround this issue ensure that the `CancellationToken` passed to client or bi-directional streaming calls is only ever canceled after the call has started.
|
||||
|
||||
- **Using the @ref automatic backing field feature result in build errors**
|
||||
- **[RESOLVED] Using the @ref automatic backing field feature result in build errors**
|
||||
|
||||
We added a productivity feature in Blazor to automatically generate backing fields for elements that utilized the `@ref` attribute. Unfortunately, we missed a critical design flaw which prevents this from working end-to-end. For more information check out the corresponding [announcement](https://github.com/aspnet/Announcements/issues/381).
|
||||
|
||||
### Preview 7
|
||||
|
||||
- **Incorrect launch URL for the Web API template**
|
||||
- **[RESOLVED] Incorrect launch URL for the Web API template**
|
||||
|
||||
The Web API template was updated to generate a `WeatherForecastController` instead of a `ValuesController`, but the launch URL was not updated accordingly. As a result Visual Studio launches the browser at the wrong URL for the Web API, which results in a 404 response. To work around this issue update the *Properties/launchSettings.json* file to change the launch URL from "api/values" to "weatherforecast".
|
||||
|
||||
### Preview 6
|
||||
|
||||
- **Publishing an ASP.NET Core hosted client-side Blazor app to Azure as a self-contained app fails**
|
||||
- **[RESOLVED] Publishing an ASP.NET Core hosted client-side Blazor app to Azure as a self-contained app fails**
|
||||
|
||||
Publishing an ASP.NET Core hosted client-side Blazor app to Azure as a self-contained app fails with the following error:
|
||||
|
||||
|
|
@ -90,7 +106,7 @@ To update the path for every new terminal session, the `export` entry will need
|
|||
|
||||
To work around this issue remove the `<TargetFramework>netcoreapp3.0</TargetFramework>` line from the generated pubxml file under *Properties\Publish Profiles<profilename>.pubxml*.
|
||||
|
||||
- **Cancellation is not sent to the server when using the `Grpc.Net.Client` gRPC client**
|
||||
- **[RESOLVED] Cancellation is not sent to the server when using the `Grpc.Net.Client` gRPC client**
|
||||
|
||||
Canceling a gRPC client will cancel the call on the client, but will not send a cancellation notification to the server.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue