Create project from existing code, point it at the following code somewhere on disk:
https://github.com/nitrogenjs/service
Right click on project and do Update npm Modules
It looks like it will install all the modules listed in the package.json (there are several). VS will be pretty slow while this happens, and it will stay slow even after it looks like it's done installing (high cpu usage for more than 5 mins).
Comments: Aha, I know what this is now, and it's not the npm stuff. The problem is in the hierarchy. Here's the extract from an email I sent to dinov earlier about precisely this issue: _I've just run into something that you might already be aware of. I'm taking a look at https://nodejstools.codeplex.com/workitem/563 right now and, having run an npm install command with the supplied package.json (which works fine) I've found that Visual Studio has become unresponsive and is thrashing the CPU. The npm install will result in quite a wide, and deep, package hierarchy being installed so I surmise it's something to do with the VS hierarchy rescanning the package directory tree. Here's the stack trace I get out of the debugger. mscorlib.dll!System.IO.PathHelper.GetFullPathName() + 0x182 bytes mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck, int maxPathLength, bool expandShortPaths) + 0x385 bytes mscorlib.dll!System.IO.Path.GetFullPathInternal(string path) + 0x32 bytes mscorlib.dll!System.IO.Directory.InternalExistsHelper(string path, bool checkHost) + 0x39 bytes mscorlib.dll!System.IO.Directory.Exists(string path) + 0xa bytes > Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.IsFileHidden(string path) Line 788 + 0x19 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.DiskMerger.ContinueMerge(bool hierarchyCreated) Line 667 + 0x10 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.MergeDiskNodes(Microsoft.VisualStudioTools.Project.HierarchyNode curParent, string dir) Line 700 + 0x11 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.FileSystemChange.ChildCreated(Microsoft.VisualStudioTools.Project.HierarchyNode child) Line 1130 + 0x22 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.FileSystemChange.ProcessChange() Line 1033 + 0xb bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.OnIdle(object sender, Microsoft.VisualStudioTools.ComponentManagerEventArgs e) Line 981 + 0xa bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectPackage.FDoIdle(uint grfidlef) Line 180 + 0x2c bytes C# [Native to Managed Transition] It does calm down again after a few minutes once the scan is complete so you can carry on working again. This is in 2012, btw, and I imagine it would hang for a shorter period if I weren't running in the debugger._
https://github.com/nitrogenjs/service
Right click on project and do Update npm Modules
It looks like it will install all the modules listed in the package.json (there are several). VS will be pretty slow while this happens, and it will stay slow even after it looks like it's done installing (high cpu usage for more than 5 mins).
Comments: Aha, I know what this is now, and it's not the npm stuff. The problem is in the hierarchy. Here's the extract from an email I sent to dinov earlier about precisely this issue: _I've just run into something that you might already be aware of. I'm taking a look at https://nodejstools.codeplex.com/workitem/563 right now and, having run an npm install command with the supplied package.json (which works fine) I've found that Visual Studio has become unresponsive and is thrashing the CPU. The npm install will result in quite a wide, and deep, package hierarchy being installed so I surmise it's something to do with the VS hierarchy rescanning the package directory tree. Here's the stack trace I get out of the debugger. mscorlib.dll!System.IO.PathHelper.GetFullPathName() + 0x182 bytes mscorlib.dll!System.IO.Path.NormalizePath(string path, bool fullCheck, int maxPathLength, bool expandShortPaths) + 0x385 bytes mscorlib.dll!System.IO.Path.GetFullPathInternal(string path) + 0x32 bytes mscorlib.dll!System.IO.Directory.InternalExistsHelper(string path, bool checkHost) + 0x39 bytes mscorlib.dll!System.IO.Directory.Exists(string path) + 0xa bytes > Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.IsFileHidden(string path) Line 788 + 0x19 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.DiskMerger.ContinueMerge(bool hierarchyCreated) Line 667 + 0x10 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.MergeDiskNodes(Microsoft.VisualStudioTools.Project.HierarchyNode curParent, string dir) Line 700 + 0x11 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.FileSystemChange.ChildCreated(Microsoft.VisualStudioTools.Project.HierarchyNode child) Line 1130 + 0x22 bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.FileSystemChange.ProcessChange() Line 1033 + 0xb bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.OnIdle(object sender, Microsoft.VisualStudioTools.ComponentManagerEventArgs e) Line 981 + 0xa bytes C# Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectPackage.FDoIdle(uint grfidlef) Line 180 + 0x2c bytes C# [Native to Managed Transition] It does calm down again after a few minutes once the scan is complete so you can carry on working again. This is in 2012, btw, and I imagine it would hang for a shorter period if I weren't running in the debugger._