Home: restore: Received an unexpected EOF or 0 bytes from the transport stream

[obeyda]

Details about Problem

product used (mcr.microsoft.com/dotnet/core/sdk:3.1-buster):

dotnet.exe --version:

   docker run --rm mcr.microsoft.com/dotnet/core/sdk:3.1-buster dotnet --version
   3.1.100

OS version (i.e. win10 v1607 (14393.321)):

   docker-desktop on windows 10 
   OS Name:                   Microsoft Windows 10 Pro Insider Preview
   OS Version:                10.0.19536 N/A Build 19536

Detailed repro steps so we can see the same problem

restore a project from a solution with a big number of nuget packages and projects (>50 project), no issues for smaller solutions.

Other suggested things

this works with --disable-parallel flag but it takes >20min to complete

Logs

normal verbosity -v:n
diag verbosity -v:d

[dh-ger]

I can confirm that I am seeing this behavior on the following images:

mcr.microsoft.com/dotnet/core/sdk:3.0
mcr.microsoft.com/dotnet/core/sdk:3.0-alpine

[MichaelPetrinolis]

I also confirm the same behavior, on 3.0:latest and on 3.1:latest on docker for windows 2.2.0.0
--disable-parallel works but it takes a huge amount of time.

[sergioprates]

Try add Nuget.config file in project and copy the file to container.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

[MichaelPetrinolis]

my project has a nuget.config file with nuget and a myget source but it makes no difference

[sergioprates]

But in dotnet restore, are you passing the file?

RUN dotnet restore --configfile ./nuget.config

[MichaelPetrinolis]

it uses it by default. To test it, I added a local package source that does not exist on docker image and the build fails, because it cannot find the source.

[xVinCe]

I have the same issue on a single project with ~20 packages referenced (Serilog, EF Core, EPPlus) mcr.microsoft.com/dotnet/core/sdk:3.1

I have a slow network at home (~2Mbps), I guess that explains it.
--disable-parallel flag works, takes 6 minutes

[strizzwald]

I've got the same issue with 63 packages referenced, using mcr.microsoft.com/dotnet/core/sdk:3.1. Adding nuget.config didn't resolve the issue for me.

[shaunsales]

Same issue here at 70 package references. I hope this gets some attention, it's slowing down our build & run iteration time in VS quite a bit.

I've tested on a 10Mbps connection vs 1Gbps connection and it seems bandwidth related - i.e. NuGet tries to connect, times out too quickly and then fails with the error above.

[obeyda]

can't we control the max number of concurrent connections? since --disable-parallel solves the issue (at least for me, but it takes a long time as i said)

[aortiz-msft]

Seems like a dupe of https://github.com/NuGet/Home/issues/8571. Please try the solution discussed in that issue.

[shaunsales]

@aortiz-msft I don't think it's related - the error is not the same. I've tested on the same solution with different bandwidth speeds, and this issue occurs only on the slower connection.

[Gorithow]

@aortiz-msft I don't think it's related - the error is not the same. I've tested on the same solution with different bandwidth speeds, and this issue occurs only on the slower connection.

True. And solution with ulimit -n 8192 did not help me at all.

[MichaelPetrinolis]

@aortiz-msft it seems that this is not related to #8571 and should not be closed.

[obeyda]

I also tried to increase the maximum number of connection by setting the two values (Linux) :

net.ipv4.ip_local_port_range
net.ipv4.tcp_fin_timeout

that didn't have any effect.

[horeeorg]

I still experienced with this issue, and I've read, still there is no solution for this issue, could you please open it again?

[rikkit]

Also experiencing this error using mcr.microsoft.com/dotnet/core/sdk:3.1 - --disable-parallel fixed it but takes longer. Run inside a Docker build inside WSL2.

[reazura]

Im getting this issue locally on mcr.microsoft.com/dotnet/core/sdk:3.1-buster as well - which is strange, it was working fine about 2 days ago. I havent tried on another machine/connection yet.

[SP-SuperPoney]

I've got the same issue.
Project retrieve Nuget artifacts from Azure at build time.

RUN dotnet restore "MyProject.csproj" fail on random packages :

Determining projects to restore... Failed to download package 'XXXX' from 'https://pkgs.dev.azure.com/[...]/nuget/v3/XXXX.nupkg'.

Error can be either :
Name does not resolve, Resource temporarily unavailable, The response ended prematurely. or Authentication failed because the remote party has closed the transport stream.

RUN dotnet restore --disable-parallel "MyProject.csproj" works but takes a lot of time.

Seem that the workaround with ulimit is per process on linux system.
And The ulimit breaks on the container.
I've added a ulimit just before the dotnet restore and it seems to do the job:

RUN ulimit -n 8192
RUN dotnet restore "MyProject.csproj"

Don't forget to change on your WSL2 distro the soft file limit: sudo vi /etc/security/limits.conf to something like
* soft nofile 8192

Notes:
I've a good DSL connexion.
Docker version 19.03.8, build afacb8b.
WSL2 with fresh Debian buster distro.

[hoopsomuah]

Why is this issue closed? This is killing my productivity and costing me a lot of money in wasted restores.

[obeyda]

@aortiz-msft, is it possible to reopen this? This is not the same issue, the error is not the same, and the proposed solution doesn't work for this problem.
This only happens with slow connections.

[timba]

Confirming the issue

Windows 10 Build 19041.450
Ubuntu 20.04 @ WSL v2
Docker Desktop Engine 19.03.8
Base image mcr.microsoft.com/dotnet/core/sdk:3.1

--disable-parallel option works but slows down dotnet restore from ~30 sec to 11 min (1 private NuGet feed used additionally to the public NuGet).

The Docker command used:

RUN dotnet restore --configfile ./NuGet.config --disable-parallel

Without --disable-parallel option the command fails with multiple Received an unexpected EOF or 0 bytes from the transport stream. errors.

Restore works fine directly on WSL.

[AndiRudi]

I have the same error in my docker-compose when I run it locally on a MacBook.

[kglassmire]

I can vouch that when using private nuget feeds, some of my team members with worse bandwidth often receive this error.

--disable-parallel 

works most of the time but even now this is not working.

[denis-ivanov]

Any solution?

[iSeiryu]

Confirming the issue

Windows Version: Windows 10 Pro 10.0.19041 Build 19041
WSL 2: Ubuntu 18.04
Docker Desktop Version: 2.3.0.5 (48029)
Docker Engine Version: 19.03.12, build 48a66213fe
Base Image: mcr.microsoft.com/dotnet/core/sdk:3.1-buster

When I run dotnet build on Windows or inside WSL it works and the whole process takes ~10 seconds.
But when I run the same command inside Dockerfile via docker build . -t test:latest it takes 2-5 minutes when it gets to Determining projects to restore... part and then starts throwing different errors.

Errors examples

 Failed to download package 'Microsoft.Extensions.Options.ConfigurationExtensions.2.0.0' from 'https://api.nuget.org/v3-flatcontainer/microsoft.extensions.options.configurationextensions/2.0.0/microsoft.extensions.options.configurationextensions.2.0.0.nupkg'.
   Received an unexpected EOF or 0 bytes from the transport stream.

 Failed to download package 'Microsoft.Extensions.DependencyInjection.Abstractions.3.1.3' from 'https://api.nuget.org/v3-flatcontainer/microsoft.extensions.dependencyinjection.abstractions/3.1.3/microsoft.extensions.dependencyinjection.abstractions.3.1.3.nupkg'.
  The SSL connection could not be established, see inner exception.
     Received an unexpected EOF or 0 bytes from the transport stream.



md5-742b5b0da1e7e29ae19dfa22e8e73105



Retrying 'FindPackagesByIdAsyncCore' for source 
  The SSL connection could not be established, see inner exception.
    Authentication failed because the remote party has closed the transport stream.



md5-742b5b0da1e7e29ae19dfa22e8e73105



Name does not resolve



md5-742b5b0da1e7e29ae19dfa22e8e73105



Failed to download package 'System.Security.Cryptography.Encoding.4.3.0' from 'https://api.nuget.org/v3-flatcontainer/system.security.cryptography.encoding/4.3.0/system.security.cryptography.encoding.4.3.0.nupkg'.
  The download of 'https://api.nuget.org/v3-flatcontainer/system.security.cryptography.encoding/4.3.0/system.security.cryptography.encoding.4.3.0.nupkg' timed out because no data was received for 60000ms.
    Exception of type 'System.TimeoutException' was thrown.

Sometimes the whole process works, sometimes it does not at all. The packages it fails on are always different. I only use https://api.nuget.org/

I can even add
RUN curl https://api.nuget.org/v3-flatcontainer/microsoft.extensions.options.configurationextensions/2.0.0/microsoft.extensions.options.configurationextensions.2.0.0.nupkg
inside my Dockerfile and it works instantly.

--disable-parallel option works but takes ~10 minutes.
It also works on the projects that only have a few nuget packages. Although I did not test it much, just ran a few test projects to confirm.

I have a pretty slow internet 4mb/s but this same command works very fast outside of Docker.

[iSeiryu]

Linking this issue https://github.com/NuGet/NuGetGallery/issues/5887
It has nothing to do with https://www.myget.org/F
It crashes for pretty much any resource.
Docker is able to pull 100+ Mb images pretty quickly but small nuget packages fail to download.

[iSeiryu]

Possible workaround

Besides --disable-parallel the following also works (most of the time).
Inside Dockerfile copy only the main project(s) first

COPY ["YourProject.csproj", "ProjectDir/"]
RUN dotnet restore "ProjectDir/YourProject.csproj"

# you can also add a nuget.config manually
RUN dotnet restore "ProjectDir/YourProject.csproj" --configfile nuget.config

# and then copy the rest of the files do the build
COPY . .
RUN dotnet build "ProjectDir/YourProject.csproj" -c Release

It outputs a lot of

Determining projects to restore...
Skipping project "/src/SomeProject/SomeProject.csproj" because it was not found.

But when it gets to dotnet build step it just works

Determining projects to restore...
Restored /src/SomeProject/SomeProject.csproj (in 5.38 sec).

There is also this article https://andrewlock.net/optimising-asp-net-core-apps-in-docker-avoiding-manually-copying-csproj-files/

[iSeiryu]

mcr.microsoft.com/dotnet/sdk:5.0
30 MB/s channel

Still the same set of errors even on small projects. The workarounds above work but are slow.
curling the same packages inside the same Dockerfile happens instantly.