after upgrading to .net 5, dotnet cli is unable to load the service index for source https://api.nuget.org/v3/index.json due to SSL connection

Viewed 1722

I was on Windows 10 working with .net core 3.1. After .net 5 was launched, I upgraded to the new version immediately. I updated my Visual Studio 2019 to version 16.8. Everything worked well in Visual Studio, but when I tried to update dotnet-ef in dotnet cli,

dotnet tool update dotnet-ef -g

I got this error:

C:\Program Files\dotnet\sdk\5.0.100\NuGet.targets(131,5): error : Unable to load the service index for source https://api.nuget.org/v3/index.json. [C:\Users\z\AppData\Local\Temp\eip3wn3x.eys\restore.csproj]

C:\Program Files\dotnet\sdk\5.0.100\NuGet.targets(131,5): error : The SSL connection could not be established, see inner exception. [C:\Users\z\AppData\Local\Temp\eip3wn3x.eys\restore.csproj]

C:\Program Files\dotnet\sdk\5.0.100\NuGet.targets(131,5): error : Received an unexpected EOF or 0 bytes from the transport stream. [C:\Users\z\AppData\Local\Temp\eip3wn3x.eys\restore.csproj]

The tool package could not be restored. Tool 'dotnetsay' failed to install. This failure may have been caused by:

  • You are attempting to install a preview release and did not use the --version option to specify the version.
  • A package by this name was found, but it was not a .NET tool.
  • The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
  • You mistyped the name of the tool.

For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool

I also tried to install the dotnetsay but got the same error:

dotnet tool install dotnetsay -g

Before upgrading to .net 5, I was able to install dotnet-ef 3.1 and everything was fine. I guess the issue mighe be caused by an invalid certificate on my local, but not sure, and I don't know which certificate is used for nuget.

Any help is appreciated.

1 Answers

I ran into the same problem with the same setup (win 10, vs 2019 16.8, .net 3.1 -> .net 5.0). For me the solution was to set a registry value as specified by this github comment by wfurt.

The solution copied from that comment:

Set the value Enabled (Dword) to 0 under the key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client

This comment by Gnbrkm41 provides a powershell script to accomplish the same.

Related