dotnet restore hangs indefinitely

[richlander]

See:

• .NET Core 2.0 Preview 2 #711 (comment)
• .NET Core 2.0 Preview 2 #711 (comment)

/cc @rrelyea

[MathiasKowoll]

I looked that while having many libs in the folder wwwroot\lib dotnet restore takes a while to restore the files, If I remove that folder it restores immediately.

This happens with al dotnet commands. CLI and Visual Studio 2017 Preview 3

[dsyme]

I put a full process dump of a hung dotnet.exe here: https://1drv.ms/u/s!Aq5gXOPBI5HdiroRLPy1hDY3yK80kQ

C:\GitHub\misc>dotnet --version
2.0.0-preview2-006497

[dsyme]

I eventually realised that I had a very large number of files in the subdirectories under the c:\misc in which I was running "dotnet". The c:\misc directory itself contained just the results of a dotnet new. The subdirectories included Git repos and much more - 20,000 files and 1.6GB

Now, it's my belief that the presence of these files shouldn't have caused problems for a simple dotnet restore but it seems they did.

I tried to procmon.exe the activity of dotnet.exe but the trace was large. The screenshot below showed that it is indeed accessing all the subdirectories, In this case, it seemed like the thing just never terminated, I don't know what it was doing though o all those blocked threads

Anyway, I think the bug here is that running dotnet.exe in a folder containing 1GB of misc files in subdirectories either takes a very long time or simply doesn't terminate

Now I know that I can get on with the rest of my work :)

[Petermarcu]

@rrelyea should this get moved to the nuget repo to get tracked?

[Lanayx]

I got the same issue. For me the problem was that new dotnet restore (from dotnet-sdk-2.0.0-preview2-006497-win-x64) ignores disabledPackageSources configuration in NuGet.Config, and I had some of them unreachable. Removing these sources helped.

[richlander]

@Petermarcu I was going to make @ https://github.com/NuGet/NuGet.Client but issues are not enabled.

[Petermarcu]

@richlander you make it on the nuget/home repo

[forki]

Same issue here: fable-compiler/Fable#1042

[rrelyea]

Working on creating NuGet/home issues ... will link when created.
Update: Actually, I lied...let's drill into these 2 issues a bit first...

[rrelyea]

@dsyme - in dotnet cli v1 previews, we used to walk all the sub directories. I had thought we changed that when we switched to make restore recursive (across project references) by defeault. do you have the same problem if you do a "dotnet restore --no-dependencies" in that same directory?

[rrelyea]

@MathiasKowoll - can you please give me repro steps for your problem (full details), and how you avoided it.

[rrelyea]

@forki - I am unable to repro.
after you have done dotnet new, a restore should have already been completed.
when you do a build, it will also do a restore, if it deems that one is necessary.
Can you please file an issue in NuGet/Home about the issue you are seeing, with repro steps (including setup steps if necessary?

[MathiasKowoll]

@rrelyea create mvc app with individual authentication.

replace bower.sjon with the following.

{
"name": "ItsomaxCms",
"private": true,
"dependencies": {
"jquery": "^3.2.1",
"jquery-ui": "1.12.1",
"bootstrap": "^3.3.7",
"font-awesome": "4.3.0",
"jquery-validation": "1.16.0",
"jquery-validation-unobtrusive": "3.2.6",
"datatables.net": "^1.10.15",
"datatables.net-bs": "^2.1.1",
"datatables.net-buttons": "^1.3.1",
"datatables.net-buttons-bs": "^1.3.1",
"datatables.net-fixedheader": "^3.1.2",
"datatables.net-fixedheader-bs": "^3.1.2",
"datatables.net-keytable": "^2.2.1",
"datatables.net-responsive": "^2.1.1",
"datatables.net-responsive-bs": "^2.1.1",
"datatables.net-scroller": "^1.4.2",
"datatables.net-scroller-bs": "^1.4.2",
"pdfmake": "^0.1.29",
"echarts": "^3.6.1",
"smartwizard": "latest",
"fastclick": "latest",
"nprogress": "latest",
"ionicons": "latest",
"slim-scroll": "latest",
"icheck": "latest",
"switchery": "latest",
"bootstrap-table": "latest",
"tableExport.jquery.plugin": "latest",
"x-editable": "latest"
},
"resolutions": {
"jspdf": "1.1.239 || 1.3.2"
}
}

make bower install

run dotnet restore.

[forki]

@rrelyea thanks for looking into this. I notified the original author of the issue. We have multiple people reporting this on the fable gitter chat. I assume it's related to node_modules and dotnet restore iterating long time over it

[forki]

Seems that things worked with preview1 see fable-compiler/Fable#1042

[davkean]

This issue was moved to NuGet/Home#5583

[davkean]

Moving this to NuGet for now, @rrelyea it seems NuGet is involved in this, if this ends up not being the case - feel free to move it a product-based repo.

[forki]

@davkean The same thing happens for dotnet build. It's probably more an issue with dotnet cli than nuget

[ctaggart]

I'm not sure where to log the bug with Azure App Services, cc @suwatch & @davidebbo.

Since 2.0.0-preview2-006497 was rolled out on Friday, our builds using Azure Kudu have gone from 5 minutes to 50 minutes. The last 5 minute build was using 2.0.0-preview1-005977.

[forki]

@ctaggart it's by design to increase your azure bill ;-)

[richlander]

@ctaggart Do you have access to logs for kudo build? If you did, we'd appreciate seeing them to help diagnose the issue. Send to rlander@ms.

[forki]

@richlander @ctaggart in the linked issues the root cause is analysed as gobbling going rogue in restore and build. Workaround dotnet restore /p:EnableDefaultItems=false

[ctaggart]

Thanks @forki, that dropped the build time down to 15 minutes. Fable is taking up about 11 minutes though, which is much longer than it was before even with the attempted workaround on that line too:

dotnet restore /p:EnableDefaultItems=false
dotnet fable npm-run build /p:EnableDefaultItems=false

[forki]

yes that's exactly the same thing. somehow all dotnet commands are broken now.

[ctaggart]

Do you have access to logs for kudo build? If you did, we'd appreciate seeing them to help diagnose the issue. Send to rlander@ms.

@richlander Diagnostics for our internal company dashboard build are in your inbox. I built it using Fable and the builds auto-deploy using Azure Kudu. We are really looking forward to a stable dotnet 2. Let me know if I can assist further.

[cartermp]

Can we open this up on the CLI since this isn't a NuGet bug?

[cartermp]

cc @livarcocc - see this: NuGet/Home#5583 (comment)

[davkean]

It's not a CLI bug either, let @emgarten figure out the cause or then it will either be against SDK or MSBuild.

[davkean]

@dsplaisted is going to investigate this.

[forki]

There is another proposed workaround NuGet/Home#5583 (comment)