I was going to create a new defect for mine, but this is the same issue I have... but under VS2010.

It looks like the repo details are the same too.

In my case I had a "Library" folder, underneath my project folder, which contains lots (1000s) of external library files (some source code, some compiled assemblies). After moving that up to beneath the solution level, it fixed my nuget updating, and I was able to update packages again.

I've had my layout like that for some time now, but it's only been an issue in the past release of Nuget (although I may be one release behind).

I could be wrong, but it looks like Nuget scans your project folder for dependencies it can re-use? I ran Procmon and it was checking every file/folder in my Library folder. Anyway, moving my Library folder to the parent folder fixed it for me. But like I say, that was only a problem from the last release or so of Nuget.

@MrField: Is the "Library" folder part of the project in VS, or is it just present on disk?

@EvilShrike: do you have a folder with lost of files like MrField does? What does your solution structure look like?

Also, what is the package that you are trying to update? Is it nuget.org? If no, can you share the package with us?

@dotnetjunky - It's just present on the disk. Just checked, and its roughly 400mb big, and contains ~17,000 files across 13,000 files.

sorry for a delay.
@dotnetjunky I have some bunch of files. But it's not so big. The package I'm trying to update is my own package. Unfortunately I can't share it as is. I tried to trim all files inside it. After I've done this it was updated successfully (and pretty fast). So now I can't share anything to help to reproduce the issue. I'll to move out all non-project files from solution directory.

@deepakverma - please try to get a repro of this. It sounds like having a solution-level folder with thousands of files can lead to NuGet improperly scanning those files and resulting in a hang.

@dotnetjunky - can you think of anything that would trigger NuGet to scan arbitrary folders in the solution?

I've encountered with the issue again, in another project. VS just hangs. The project doesn't use NuGet's 'ExcludeVersion' option (it's source of tons NuGet's bugs). There're no any large amount of files in project's folder. I also saw the same issue on other machines in other projects.
I don't understand why you mark the issue with Low impact. It's a blocking issue! I have to kill VS from ProcessExplorer. And after that all project packages are broken (updated partially!). Terrible.

I was able to repro intermittently this issue on a win7 x86 2gb box with composite c1 cms package (thought i didn't have to kill the process, instead waiting few seconds brought back the ui, may be on a slower box with larger project it repros consistently)

I am not an expert here but I had following thoughts

1. it looks like it does processing on the UI thread. if it's possible may be this work can be offloaded to background thread
2. OR may be time slice on the UI thread.Also log output on what exactly is getting added to give more details to the user what's happening right now and is taking time.
   

Did some profiling and following is the hottest path
Function Name Inclusive Samples Exclusive Samples Inclusive Samples % Exclusive Samples % Module Name
devenv.exe 2,750 0 100.00 0.00
NuGet.Tools.NuGetPackage.ShowManageLibraryPackageDialog(object,class System.EventArgs) 1,870 0 68.00 0.00 NuGet.Tools.dll
NuGet.Tools.NuGetPackage.ShowManageLibraryPackageDialog(class EnvDTE.Project,string) 1,870 0 68.00 0.00 NuGet.Tools.dll
Microsoft.VisualStudio.PlatformUI.DialogWindow.ShowModal() 1,870 1,374 68.00 49.96 Microsoft.VisualStudio.Shell.10.0.dll
NuGet.VisualStudio.VsProjectSystem.<>c__DisplayClass13.<AddFileToProject>b__12() 464 0 16.87 0.00 NuGet.VisualStudio.dll
NuGet.VisualStudio.VsProjectSystem.AddFileToContainer(string,class EnvDTE.ProjectItems) 297 1 10.80 0.04 NuGet.VisualStudio.dll

function code => ProjectItems.AddFromFileCopy

thoughts?

I have this same issue, basically a folder in my solution has hundreds of subfolders and HTML files, but they are excluded from the solution, they are generated files but all get checked when I do a Nuget install or any upgrade in the solution and it takes up Gb of memory then VS falls over, or sometimes completes after a very long delay.

I was not able to get it to repro with just dropping in large number of files underneath my project folder. If @dotnetjunky could help to check if there is any code that scans thru the content folder.

For me it seems to happen with a high number of folders and files, rather than just a large number of files.

Can you share a sample of package with lots of files in content for us to debug?

@casquith Can you draw your solution structure on disk? Where are the folders and files relative to the solution root?

Sorry for the delay - I have been trying to reproduce as much as possible, but have some weird results. To explain the rough structure, the main web application is a CMS app which manages and generates content into a Sites folder which sits in the same folder as the project, but isn't part of the solution. The sites folder contains a folder for each website in the CMS, which contains a web.config file, DLLs, XML files for pages, resources, scripts etc.

• I have 12 C# projects in my solution, there are two web applications, the rest are Class Libraries
• The Sites folder has about 50 sites on my dev machine, each site has DLLs etc. and also a folder of configs/settings for every page
• The sites folder is about 1.5Gb in size, because so many cached files are generated, but they aren't part of the solution
• If I try and do anything with Nuget in this solution, it takes >30 mins to do anything, and I get a massive memory spike
• If I move the Sites folder away from the project folder, I do NOT get a slowdown in Nuget in this solution
• If I copy the Sites folder into another project I don't get the same slowdown, Nuget is as fast as ever
• I can't share a zip of my solution or the files because they are content files for many of my companies sites, but I will see if I can generate something
• When the slowdown occurs, you can see that EVERY folder in the Sites directory is open "ghosted out" in the solution, so for some reason VS has decided to look through and visualise the structure of the directories there when you run Nuget, even though the folder/subfolders aren't part of the solution, it may parsing this massive directory structure that is the issue
  

So from my guess- it seems that either VS doesn't like the combination of this big 12 project solution with the subfolder of many files and folders, or it doesn't like that some sub-folders are mapped up as their own sites in IIS.

Sorry I can't attach a solution, I will see if I can create something to obfsucate everything or to generate similar files that have no meaning so you can repro it, but also I need to find out why just adding the files to other solutions doesn't cause the same issue.

Thanks for the information. We'll try to repro it and see if we can find out the root cause of it.

@Deepak: can you try to repro according the description below, please?

I could try to see if I can trace some extra information - such as monitor the files that are being read etc. maybe it would show if it was the opening/scanning of XML files or DLLs when I run Nuget in my solution, or if there is some trace program I can run to help you?

Yes, that would be very helpful.

Btw, when you said "EVERY folder in the Sites directory is open "ghosted out" in the solution", what do you mean?

Maybe you have a suggestion for some better tracing, but using Resource Monitor it seems:

• The entire VS UI hangs and there is no Nuget Cursor while this is happening
• CPU usage is jammed at ~50% (of my Quad core machine)
• Visual Studio is mainly reading the NTFS Master File Table and then going through every single folder in my Sites directory (which is in my main web application but isn't part of my VS solution), every folder read seems to take a few seconds in Resource Monitor, and also uses more and more memory...
  

The cursor comes back when this processing is finished, then Nuget does its thing and everything works (though system slow because devenv.exe is using 2-3 Gb of RAM. It took 1.5 hours to run update-package in Nuget.

When I say "ghosted out" I mean the Sites folder shows up because it is in the list of VS folders because "show all files" is turned on, it has a ghost folder icon - dotted line around it etc.

It seems that none of the insane memory use or hanging happens if I turn off "show all files", it hides the Sites folder and it takes about 15 seconds to run Nuget update, so it's a useful workaround!!!

Why do you have the Show All Files turned on? It should always be turned off, unless you want to add some files to the project. When you turn on the Show All Files, VS will track all those files, slowing it down.

Mainly to change or add files, or remove them from my solution where appropriate, it doesn't seem to interfere with other things I am doing so didn't see it as a factor, I'll keep turning it off to avoid Nuget etc. reading through all those folders.

I still can't repro this behavior. Deepak, can you try to repro this?

I was able to repro this issue thanks @casquith for sharing the details.
Repro:

1. Create new webapplication
2. Drop in a folder in webapplication (I had dropped in 9,377 Files, 2,360 Folders)
3. Turn on show all files
4. install a package
   Actual:
5. WalkDepthFirst traverses thru all the items that are not part of solution causing the issue
6. found that it could be fixed by only checking when child.GetProperty(__VSHPROPID.VSHPROPID_IsNonMemberItem) is false
7. this makes me think that this would also cause perf issue for folks who have projects with large number of items, or are trying to install on a solution with multiple large projects? Will create a separate issue to track it.
   

Call stack

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyItem.WalkDepthFirst(bool fVisible, NuGet.VisualStudio.VsHierarchyItem.ProcessItemDelegate processCallback, object callerObject) Line 103   C#

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyItem.WalkDepthFirst(bool fVisible, NuGet.VisualStudio.VsHierarchyItem.ProcessItemDelegate processCallback, object callerObject) Line 110 + 0x14 bytes C#

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetExpandedProjectHierarchyItems(EnvDTE.Project project) Line 67 + 0x49 bytes   C#
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetAllExpandedNodes.AnonymousMethod__0() Line 22 + 0x8 bytes    C#
[External Code] 
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetAllExpandedNodes(NuGet.VisualStudio.ISolutionManager solutionManager) Line 17 + 0x38 bytes   C#
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsCommonOperations.SaveSolutionExplorerNodeStates(NuGet.VisualStudio.ISolutionManager solutionManager) Line 41 + 0x11 bytes   C#
NuGet.Dialog10.dll!NuGet.Dialog.Providers.PackagesProviderBase.SaveExpandedNodes() Line 709 + 0x25 bytes    C#
NuGet.Dialog10.dll!NuGet.Dialog.Providers.PackagesProviderBase.Execute(NuGet.Dialog.Providers.PackageItem item) Line 341 + 0x8 bytes    C#
NuGet.Dialog10.dll!NuGet.Dialog.PackageManagerWindow.ExecutedPackageCommand(object sender, System.Windows.Input.ExecutedRoutedEventArgs e) Line 380 + 0xe bytes C#

call stack:

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyItem.WalkDepthFirst(bool fVisible, NuGet.VisualStudio.VsHierarchyItem.ProcessItemDelegate processCallback, object callerObject) Line 103   C#

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyItem.WalkDepthFirst(bool fVisible, NuGet.VisualStudio.VsHierarchyItem.ProcessItemDelegate processCallback, object callerObject) Line 110 + 0x14 bytes C#

NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetExpandedProjectHierarchyItems(EnvDTE.Project project) Line 67 + 0x49 bytes   C#
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetAllExpandedNodes.AnonymousMethod__0() Line 22 + 0x8 bytes    C#
[External Code] 
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsHierarchyHelper.GetAllExpandedNodes(NuGet.VisualStudio.ISolutionManager solutionManager) Line 17 + 0x38 bytes   C#
NuGet.VisualStudio.dll!NuGet.VisualStudio.VsCommonOperations.SaveSolutionExplorerNodeStates(NuGet.VisualStudio.ISolutionManager solutionManager) Line 41 + 0x11 bytes   C#
NuGet.Dialog10.dll!NuGet.Dialog.Providers.PackagesProviderBase.SaveExpandedNodes() Line 709 + 0x25 bytes    C#
NuGet.Dialog10.dll!NuGet.Dialog.Providers.PackagesProviderBase.Execute(NuGet.Dialog.Providers.PackageItem item) Line 341 + 0x8 bytes    C#
NuGet.Dialog10.dll!NuGet.Dialog.PackageManagerWindow.ExecutedPackageCommand(object sender, System.Windows.Input.ExecutedRoutedEventArgs e) Line 380 + 0xe bytes C#

Great investigation. Thanks

Fixed in changeset d89159c51b7a

Verified that perf has improved with the fix when there are project items that are not included in the solution.

** Closed by deepakverma 11/28/2012 11:48AM

Wow. It fixed! When to expect 2.2 to be released? I'm suffering from the issue very much.

Well, I looked into changes made for the issue. I guess that if "Manage NuGet Packages" dialog hangs (it still hangs!) with "Show All Files" option turned off then the fix will not solve the bug :(

Great work @deepakverma - it seems to describe the exact problem I was seeing, that all files, regardless of in or out of solution (or even their type) caused extra processing (memory and CPU). Thanks for your time and sleuthing!

On 2.2 Update dialog still hangs.

@EvilShrike it looks like then you are running into a different scenario than @casquith and @MrField

For trying to repro the issue, can you please help with the following

1. what's your project type/structure. Are there large number of projects in the solutions?
2. Which packages are installed?
3. You said in one of the prev comments you have few private packages. Can you please share the structure of the package and does it contain large number of files under content folder? what's the size of the package?
4. any other info that you think could be helpful to find the cause.
   

thanks.

Dear @deepakverma
Here you can find some more info on my environment (I posted on 12th of October) - http://nuget.codeplex.com/discussions/398667 I described my package structure.
As for project structure I looks similar to the package. Package size is about 3Mb

@deepakverma
Please read all other posts in the mentioned thread. @nootn reported that he experienced the same issue and it relates to TFS. I can confirm. It defetetely relates to TFS. I.e. the issue takes place only in TFS-binded projects.

So, I tried @EvilShrike's scenario with a large package and project mapped to TFS.
I didn't see VS hanging but it took ~5 minutes to upgrade the package.

Here is what I found could be improved:
When the older version of package is being uninstalled it calls Nuget.VisualStudio.ProjectExtensions.GetProjectItems() which tries to verify that the folder for the package content exists in the project.

For my package I saw this function is been called repeatedly to check same set of folders.
scripts\tinymce\plugins\inlinepopups\skins\clearlooks2\img
scripts\tinymce\plugins\inlinepopups\skins\clearlooks2\img
scripts\tinymce\plugins\inlinepopups\skins\clearlooks2\img

This can be improved by caching the folders that have already been created, which should help in reducing the dte calls and improving the perf.

@deepakverma slowness of updating packages in tfs-connected project is another issue, see http://nuget.codeplex.com/workitem/2531

@EvilShrike:

Can you try installing the attached VSIX and see if VS still freezes?

@dotnetjunky: I've installed the attached package and tried again. Unfortunately VS still hangs.

Are you sure it's actually hang or it's just trying to update files in the background? If you run process explorer, do you see any disk activities?

Yes. I've checked one more time (removed and reinstalled nuget to be sure). There're no disk activity (Read/Write IO Deltas are all zero in procexp). Threads continues to start and die, mostly in clr.dll!DllGetClassObjectInternal, and east some cpu (3% total).

Hmm, at this time, I don't know what else I can do. Would you want to debug it?

@dotnetjunky
I've tried to debug. I can see that a worker thread hangs on ProjectItem.Delete call in ProjectExtensions.cs:

    public static bool DeleteProjectItem(this Project project, string path)
    {
        ProjectItem projectItem = GetProjectItem(project, path);
        if (projectItem == null)
        {
            return false;
        }

        projectItem.Delete();  // here!!
        return true;
    }

path=content\vendor\colorbox\images\loading.gif

Thanks for spending time debugging this. Is it possible for you to share the actual package?

One more thing is, when you try to update packages, are the files in your project all checked in, or checked out?

This is likely caused by TFS connection issue. We can't repro this issue. Please reactivate if you find more tips that can help us repro

** Closed by dotnetjunky 03/26/2013 2:57PM

Fixed in changeset d89159c51b7a4945b92541ad58822dbf3e7a1fcb

The 3/28 fix was a codeplex bug. EvilShrike's issue was not fully addressed.

Installed NuGet 2.5 with little hope. But the bug is still here - VS hangs.

dotnetjunky wrote Feb 12 at 3:16 AM
"One more thing is, when you try to update packages, are the files in your project all checked in, or checked out?"
All files are checked in.
I can't share our packages as is. But I guess the issue root is not in the package's content itself.

Our TFS Server is of 2010 version. Did you test updating with TFS Server 2010?

Important: updating (actually removing previously installed packages) hangs ONLY in VS 2012. In VS2010 I managed to update my package successfully.

We have the issue too when launching NuGet 2.5 from the Tools | Library Package Manager | Manage NuGet Packages for Solution menu in VS 2012. We did not experience this problem in VS 2010 and the same version of NuGet. We were able to work around this problem by checking out the packages.config and web.config and then managing NuGet packages by right clicking on the project and selecting Manage NuGet Packages... from the menu that appears.

We are using Source Gear Vault 6.