search

dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.95k stars 4.9k forks source link

dotnet restore hangs indefinitely #724

Closed richlander closed 7 years ago

richlander commented 7 years ago

See:

/cc @rrelyea

MathiasKowoll commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

capture

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 commented 7 years ago

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

Lanayx commented 7 years ago

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 commented 7 years ago

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

Petermarcu commented 7 years ago

@richlander you make it on the nuget/home repo

forki commented 7 years ago

Same issue here: https://github.com/fable-compiler/Fable/issues/1042

rrelyea commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

rrelyea commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

Seems that things worked with preview1 see https://github.com/fable-compiler/Fable/issues/1042

davkean commented 7 years ago

This issue was moved to NuGet/Home#5583

davkean commented 7 years ago

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 commented 7 years ago

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

ctaggart commented 7 years ago

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 commented 7 years ago

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

richlander commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

ctaggart commented 7 years ago

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 commented 7 years ago

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

cartermp commented 7 years ago

cc @livarcocc - see this: https://github.com/NuGet/Home/issues/5583#issuecomment-314588738

davkean commented 7 years ago

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

davkean commented 7 years ago

@dsplaisted is going to investigate this.

forki commented 7 years ago

There is another proposed workaround https://github.com/NuGet/Home/issues/5583#issuecomment-316227772