.NET 5 Preview 3

[rbhanda]

Release Notes

Please report any issues you find with .NET 5, either responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• aspnet/Home - for ASP.NET Core questions
• aspnet/EntityFrameworkCore - for Entity Framework Core questions
• dotnet/sdk - for CLI tools and questions
• dotnet/runtime - for runtime, API, or installer issues and questions
• dotnet/winforms - for Winforms issues
• dotnet/wpf - for WPF issues
• nuget/home - for NuGet questions and issues

---

Here is a list of issues that we are tracking and working to resolve with this release. We'll tick them off as each is resolved. See any linked issue for progress or resolution details.

• Unable to install dotnet-sdk if machine never had .NET installed

[tareksharbak]

I'm facing an issue while trying to connect to Cosmos DB from an ASP.NET 5.0 project.

Using the latest Microsoft.Azure.Cosmos library v3.8.0, and .NET 5.0, I get the following error
"The remote certificate is invalid according to the validation procedure."

This error only occurs when running inside a docker container (Linux), it happens in both Docker for Windows with Linux containers or inside AKS.

The error doesn't occur when running the application using "dotnet run"

Downgrading to .Net Core 3.1 without making any other change, fixes the issue.

---

Full exception:
Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: InternalServerError (500); Substatus: 0; ActivityId: 00000000-0000-0000-0000-000000000000; Reason: (The remote certificate is invalid according to the validation procedure.);
---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
--- End of inner exception stack trace ---
at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception)
at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
at System.Net.Http.ConnectHelper.EstablishSslConnectionAsyncCore(Stream stream, SslClientAuthenticationOptions sslOptions, CancellationToken cancellationToken)
{"Summary":{"StartUtc":"2020-05-03T19:41:08.4368353Z","RunningElapsedTime":"00:00:00.4793436","UserAgent":"cosmos-netstandard-sdk/3.8.0|3.7.1|32522|X64|Linux 4.19.76-linuxkit 1 SMP |.NET Core 5.0.0-preview.3.20214.6|","TotalRequestCount":0,"FailedRequestCount":0},"Context":[]}

[leecow]

@anurse - any guidance here?

[analogrelay]

Looks more like @karelz ’s team. It’s HttpClient and SslStream on the stack :)

[karelz]

@tareksharbak this is weird. Would you mind to file a separate new issue in dotnet/runtime repo to get to the bottom of this?
Is there any chance you could try to isolate the repro into something we can try? Alternatively @wfurt should be able to suggest some logging to understand more of it.
Thanks!

[wfurt]

Probably missing root CA files or access to them. I would suggest to create separate issue with specific details.

[tareksharbak]

I opened a new issue with more details and a clearer repro steps Issue 35874

[jeroen-mostert]

Something I couldn't glean from the release notes or the initial announcement of .NET 5: is there an intent to supply a migration path in VS for existing Framework projects which will "just work" for most cases? Right now we only have things like the portability analyzer, the unsupported dotnet try-convert and plenty of guides on how to manually tackle conversion, but then Core isn't yet the One True Framework like it will be later.

Note that I'm not fishing for an official commitment or a time frame, just curious if MS intends to produce an officially supported migration path that happens to work well in most cases, or if the idea is that you have to put in the work manually and if that's too much work the alternative is to stick with Framework. (If this isn't the right venue for the question, please redirect.)

[mairaw]

Closing in favor of #4873

@jeroen-mostert currently there are no plans for a migration path in VS.