Closed rrelyea closed 7 years ago
@alpaix any updates on this issue? This has a fairly high hit count. Not clear if all 43 hits are from NuGet however.
Probably not fixed. Need to investigate. 34 hits in RC2. 1 hit in RC3.
1 hit on RC.4 it looks like this may have been improved by: NuGet/NuGet.Client@abb6b0e964e1eb3ee89bd9003db0c056fbd285e7 and looking at that hit, it doesn't look like we are involved.
In investigating the hang dump from RC.4 I do not see NuGet.SolutionRestoreManager as loaded in the hang. I believe a different VSIX is causing these remaining hangs.
The original issue with NuGet seems to be fixed.
Old title: [Watson] apphangb1: APPLICATION_HANG_BusyHang_cfffffff_Microsoft.VisualStudio.Shell.15.0.dll!Microsoft.VisualStudio.Shell.VsTaskLibraryHelper+cDisplayClass24_0_1+AsVsTask_b__1_d[[System.Canon,_mscorlib]].MoveNext
Notes from Internal bug: 369371 This is a deadlock in initializing an async package
The package being initialized is NuGet.SolutionRestoreManager.RestoreManagerPackage. From msenv.dll!CVsPackageMgr::CVsPackageInfo::SitePackage: // THREADING: This will deadlock if the users async task needs to run code on the UI thread // to complete and they have scheduled it using the WPF dispatcher (directly, which would be // very hard for an async loading package, or indirectly via something like ThreadHelper.BeginInvoke). // What they need to do is use the task library stuff or joinable task factory instead. If you are // investigating a deadlock in your package and are reading this under the debugger then 'they' means // 'you'.