dotnet restore consistently times out on Win7x64

[blackdwarf]

Steps to reproduce

Install the LKG version off of https://dotnet.github.io/getting-started/ and install. Then do the following:

mkdir new
cd new
dotnet new
dotnet restore

Expected behavior

The packages are restored and the lock file is generated.

Actual behavior

Works very slowly at first and then it starts spitting out messages like the one below. After a while, simply exists with restore not done.

info :   GET https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.text.encoding.extensions/index.json
log  : Retrying 'FindPackagesByIdAsync' for source https://api.nuget.org/v3-flatcontainer/system.text.encoding.extensions/index.json.
log  : The HTTP request to 'GET https://api.nuget.org/v3-flatcontainer/system.text.encoding.extensions/index.json' has timed out after 100000ms.
info :   GET https://api.nuget.org/v3-flatcontainer/system.text.encoding.extensions/index.json
log  : Retrying 'FindPackagesByIdAsync' for source https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-core/nuget/v3/flatcontainer/system.threading/index.json.

Environment data

dotnet --version output:

.NET Command Line Tools (1.0.0-beta-001598)

Product Information:
 Version:     1.0.0-beta-001598
 Commit Sha:  7582649f88

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 Runtime Id:  win7-x64

Also tested on a Linux VM that is connected to the same network, same version installed from the feed, no problems, restores fast and nice.

/cc @emgarten @piotrpMSFT

[TheRealPiotrP]

@emgarten this looks like a NuGet xplat issue. Do you need any extra info to investigate?

[emgarten]

@blackdwarf does clearing your nuget packages folder and v3-cache help? I have seen this happen before when there is an invalid cache file.

Does --disable-parallel help at all?

[blackdwarf]

@emgarten where is the v3-cache?

[blackdwarf]

@emgarten nope, cleaning the packages folder doesn't do anything. --disable-paralell is also not helping. The weird thing is that on the same network (I thought it could've been a network issue) a Linux Mint VM is restoring perfectly well.

[HermanEldering]

I am seeing the same problem. It seems that in my case the traffic was routed to an incorrect network interface. I've disabled the VirtualBox interface (earlier I had it running with a VM in host-only network mode). There also was OpenVPN running with an active VPN connection, I closed the connection but did not disable the interface. I also disabled all other network interfaces (bluetooth and unconnected wired ethernet port).

I haven't seen this problem with other software while the VPN and VirtualBox are active regularly on my system.

[blackdwarf]

@HermanEldering yup, disabling the VBox interface actually made it work! However, as you specify, this has not been the case with other software on my box. @emgarten we should still look into why this is happening. I will add this to the known issues page if anyone else encounters it.

[steelheaddigital]

@blackdwarf and @HermanEldering, same problem and same fix. Disabling the VBox interface fixed everything.

[blackdwarf]

@emgarten would be good to investigate what is happening here.

[emgarten]

@blackdwarf what are simplest repro steps for this issue?

//cc @joelverhagen

[blackdwarf]

@emgarten install Win7SP1, install Virtual Box, install CLI tools. Do:

dotnet new
dotnet restore

[mrmeek]

I just reproed this on my Win7x64 machine using latest betas. Installed Most recent Virtual Box x64 yesterday, dotnet restore stops working... Disabling 'VirtualBox Host-Only Network' adapter resolves the issue.

dotnet --info
.NET Command Line Tools (1.0.0-beta-002279)

Product Information:
Version: 1.0.0-beta-002279
Commit Sha: 76610c4

Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64

[jtbm37]

@blackdwarf the workaround for win7 in virtualbox is not working for me anymore. I cannot restore even though the virtualbox host adapter has been disabled (and completely removed)

$ dotnet --info

.NET Command Line Tools (1.0.0-preview1-002700)

Product Information:
 Version:     1.0.0-preview1-002700
 Commit Sha:  0336f6bb34

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64

ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : hostname-PC
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : tt01

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . : tt01
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-E4-37-E5
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.0.2.15(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : 11 May 2016 10:58:26
   Lease Expires . . . . . . . . . . : 12 May 2016 10:58:29
   Default Gateway . . . . . . . . . : 10.0.2.2
   DHCP Server . . . . . . . . . . . : 10.0.2.2
   DNS Servers . . . . . . . . . . . : 8.8.8.8                                           
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.tt01:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : tt01
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter dotnet/sdk#4284
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

[blackdwarf]

@emgarten can you check if this regressed?

[blackdwarf]

Hm, I cannot repro it on my box. @jtbm37 what is the version of VBox that you have installed?

[jtbm37]

@blackdwarf 5.0.20 r106931 on Ubuntu 15.04

[blackdwarf]

Yes, my VBox is in 4.3.x range. Interesting...

[emgarten]

There hasn't been a fix for this yet. There have been some improvements around bad network connections, but the root cause of why restore has trouble on VBox hasn't been tracked down yet.

[emgarten]

Would someone hitting this issue try creating a basic repro of this to see if this happens just from using HttpClient or if this is specific to how NuGet sets up HttpClient?

For reference the NuGet wrapper for HttpClient is here: https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Protocol.Core.v3/HttpSource/HttpSource.cs (NuGet.Protocol.Core.v3) package on nuget.org.

[joelverhagen]

Another interesting data point would be PowerShell:

Invoke-WebRequest https://api.nuget.org/v3/index.json

[blackdwarf]

@emgarten I can do this. You mean just having a simple app that essentially does a HttpClient call to an URL?

[emgarten]

@blackdwarf yeah, just an httpclient url request.

[jtbm37]

Invoke-WebRequest https://api.nuget.org/v3/index.json

StatusCode        : 200
StatusDescription : OK
Content           : {123, 10, 32, 32...}
RawContent        : HTTP/1.1 200 OK
                    Content-MD5: Nn3l2HC1vNHkG5AdlCykgg==
                    Vary: Accept-Encoding
                    X-Cache: HIT
                    X-CDN-Rewrite: Lowercase blobs in v3-flatcontainer
                    x-ms-blob-type: BlockBlob
                    x-ms-lease-status: unlocked...
Headers           : {[Content-MD5, Nn3l2HC1vNHkG5AdlCykgg==], [Vary, Accept-Encoding], [X-Cache, HIT], [X-CDN-Rewrite, Lowercase blobs in v3-flatcontainer]...}
RawContentLength  : 7433

PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.18063
BuildVersion                   6.3.9600.16406
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2

[jtbm37]

@blackdwarf I reinstalled virtualbox-4.3 but still no luck. I am not sure what changed.

[shrayasr]

@blackdwarf I had the very same issue and with help from the .NET slack, I got here.

Disabling the VirtualBox Adapter fixed it for me

---

Here's what I did:

> cd work\code
> mkdir tryrc2
> cd tryrc2
> dotnet new
> dotnet restore

This went slow at the start and then eventually pooped out with

error: Failed to retrieve information from remote source 'https://api.nuget.org/v3-flatcontainer/system.threading.tasks.dataflow/index.json'.
error: The HTTP request to 'GET https://api.nuget.org/v3-flatcontainer/system.threading.tasks.dataflow/index.json' has timed out after 100000ms.
error: Failed to retrieve information from remote source 'https://api.nuget.org/v3-flatcontainer/system.threading.tasks.dataflow/index.json'.
error:   The HTTP request to 'GET https://api.nuget.org/v3-flatcontainer/system.threading.tasks.dataflow/index.json' has timed out after 100000ms.

My OS is Windows 7 SP1 x64

λ dotnet --info                                  
.NET Command Line Tools (1.0.0-preview1-002702)  

Product Information:                             
 Version:     1.0.0-preview1-002702              
 Commit Sha:  6cde21225e                         

Runtime Environment:                             
 OS Name:     Windows                            
 OS Version:  6.1.7601                           
 OS Platform: Windows                            
 RID:         win7-x64                           

VirtualBox is on Version 5.0.10 r 104061 (FileHippo link / VirtualBox link)

---

Let me know if you need any other details.

[jtbm37]

I don't know how but after several attempts of disabling the interface and rebooting the vm, it finally worked. I could finally restore a new project.

[mcliment]

We had a similar issue with a CI machine that has not Virtualbox installed and only one interface. The error was the same (timeout) but actually it was not a networking problem at all.

After logging in with another user (not the one CI uses) I was able to restore all the packages and logging in with the CI user consistently gave timeout errors. That was weird.

Using procmon I found something strange happening in the lock files in %TEMP%\NugetScratch. I deleted that folder and everything started to work again and CI builds now work perfectly. 😃

[dnt294]

Same here , I got GenyMotion for my Android devs; first i was thought it's because of my home network, but then i still got "timed out after 100000ms" error when trying to restore packages at my office.

My machine is Win 7 x64 SP1.

[md-gh]

I seem to have the same issue.

[drwharris]

I have the same issue.

dotnet --info
NET Command Line Tools (1.0.0-preview1-002702)

Product Information:
Version:     1.0.0-preview1-002702
Commit Sha:  6cde21225e

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64

Only one network connection and its working perfectly:

PS C:\> Invoke-WebRequest https://api.nuget.org/v3/index.json


StatusCode        : 200
StatusDescription : OK
Content           : {123, 10, 32, 32...}
RawContent        : HTTP/1.1 200 OK
                    Access-Control-Allow-Origin: *
                    Access-Control-Expose-Headers:
                    x-ms-request-id,Server,x-ms-version,Content-Length,Date,Transfer-Encoding
                    Content-MD5: Nn3l2HC1vNHkG5AdlCykgg==
                    Vary: ...
Headers           : {[Access-Control-Allow-Origin, *], [Access-Control-Expose-Headers,
                    x-ms-request-id,Server,x-ms-version,Content-Length,Date,Transfer-Encoding], [Content-MD5,
                    Nn3l2HC1vNHkG5AdlCykgg==], [Vary, Accept-Encoding]...}
RawContentLength  : 7433

[pstephens]

Can confirm with the same problem: long delay and then timeout errors.

Fix was to disable all extraneous network interfaces; in my case VMWare and bluetooth. I didn't try and narrow down the exact interface that was causing the trouble. Ended up with two interfaces enabled: LAN and wireless.

Dotnet CLI version:

C:\src\scratch\hwapp> dotnet --info
.NET Command Line Tools (1.0.0-preview2-003121)

Product Information:
 Version:            1.0.0-preview2-003121
 Commit SHA-1 hash:  1e9d529bc5

Runtime Environment:
 OS Name:     Windows
 OS Version:  6.1.7601
 OS Platform: Windows
 RID:         win7-x64

[blackdwarf]

I will close this issue as we have one on NuGet/Home that is tracking this work.

[WhiteKarma]

Hello all,

I had the same problem upgraded the powershell to version 3 and now it is working fine. I used the link below:
https://www.microsoft.com/en-us/download/details.aspx?id=34595

All the best

[ti24horas]

@WhiteKarma why should be powershell related to dotnet restore timeouts. Is dotnet using powershell commands or scripts?

[mcaden]

I had the same problem. I too had VMWare interfaces. However, the weird part is nuget restore itself runs fine. It's strictly dotnet restore that does not work with this issue.

I disabled the VMWare interfaces and instead of magically working, I got a 407 proxy error on dotnet restore. Again - nuget restore worked fine.

I found my company's proxy configuration and manually plugged it into nuget.config. dotnet restore finally works whether the VMWare ethernet interfaces are enabled or not. Could there be something about the way that dotnet restore is using nuget that is not picking up automated proxy stuff even though nuget itself handles it fine?