Report from dinov:
If a package.json doesn’t have a name that we blow up (we end up storing in the dictionary of names and it’s a null name). I ran into it the other day and haven’t had a chance to check if there’s a bug on it yet or open one. Someone also sent me a report this morning of a null reference exception here:
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodeModulesNode.ReloadHierarchy() + 0xa0 bytes
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodeModulesNode.ReloadHierarchySafe() + 0x47 bytes
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodejsProjectNode.Reload() + 0xe9 bytes
Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.ProjectNode.Load(string fileName, string location, string name, uint flags, ref System.Guid iidProject, out int canceled) + 0x52b bytes
Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.Load(string filename, string location, string name, uint flags, ref System.Guid iidProject, out int canceled) + 0x4c bytes
Not quite sure what would cause that but I figured you will. I can open bugs on them if you’d like.
Comments: I couldn't reproduce this, but I think I know why it was occurring. It's possible that the package at the root of the hierarchy, i.e., the one for the user's project, could have been null. During and subsequent to the hackathon I made some changes that should, at least mostly, ensure that this doesn't happen. To be on the safe side I've also added a null check before attempting to use the root package to repopulate the npm hierarchy. Fix is in commit eaeffa0bd3b6 at https://nodejstools.codeplex.com/SourceControl/network/forks/BartRead/rgnpm01/changeset/eaeffa0bd3b612a86a624a22da2d8041b4124766.
If a package.json doesn’t have a name that we blow up (we end up storing in the dictionary of names and it’s a null name). I ran into it the other day and haven’t had a chance to check if there’s a bug on it yet or open one. Someone also sent me a report this morning of a null reference exception here:
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodeModulesNode.ReloadHierarchy() + 0xa0 bytes
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodeModulesNode.ReloadHierarchySafe() + 0x47 bytes
Microsoft.NodejsTools.dll!Microsoft.NodejsTools.Project.NodejsProjectNode.Reload() + 0xe9 bytes
Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.ProjectNode.Load(string fileName, string location, string name, uint flags, ref System.Guid iidProject, out int canceled) + 0x52b bytes
Microsoft.NodejsTools.dll!Microsoft.VisualStudioTools.Project.CommonProjectNode.Load(string filename, string location, string name, uint flags, ref System.Guid iidProject, out int canceled) + 0x4c bytes
Not quite sure what would cause that but I figured you will. I can open bugs on them if you’d like.
Comments: I couldn't reproduce this, but I think I know why it was occurring. It's possible that the package at the root of the hierarchy, i.e., the one for the user's project, could have been null. During and subsequent to the hackathon I made some changes that should, at least mostly, ensure that this doesn't happen. To be on the safe side I've also added a null check before attempting to use the root package to repopulate the npm hierarchy. Fix is in commit eaeffa0bd3b6 at https://nodejstools.codeplex.com/SourceControl/network/forks/BartRead/rgnpm01/changeset/eaeffa0bd3b612a86a624a22da2d8041b4124766.