-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VS2015 crashes every time I update npm package version #361
Comments
Thx for reporting this. Since VS crashed, there should be a corresponding entry (or entries) in the windows event log. Mind grabbing that for us? Also can you be a little more specific about how you're updating the package version? Are you using the context menu command, or something else? |
@mousetraps where is log? I can't find it in C:\user\username\AppData\Roaming\Microsoft\VisualStudio\14.0 package doesn't matter I think, this time mongoose 4.1.1 -> 4.1.2, I usually just modify package.json and save and then addon run script automatically anyway package was updated successfully after these crash and restart |
Control Panel > System and Security > Administrative Tools > Event Viewer |
Or just use the "Windows Key + X" (the handiest but least known Windows shortcut) to open the menu, and then press "V" (for Event Viewer). p.s. "Win + X, A" is another super handy combo I use all the time for an Admin prompt. |
p.s. The log to look at will be under 'Windows Logs / Application'. Most app crashes get an event in here. |
@mousetraps 2 errors occured one other right after one
looks like this is caused by "Too long path" related. similar to warning when I first try to build my node.js project. |
This is an unfortunately limitation of .NET that impacts some Node projects due to the way node modules nest in the file system (see http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx ). As a potential workaround, is the project stored at an already lengthy path (e.g. "C:\users\some name\documents\visual studio 2015...")? If so, can you try moving the project to somewhere like "C:\src" and seeing if the problem persists? |
(note: that doesn't change the fact this shouldn't crash and we need to handle this exception better - and give useful guidance when caught - but hopefully that will unblock you) |
I think this might actually be coming from web tools, not from ntvs - he mentioned that the script is run immediately after he saves. |
@billti my project is like F:\VSWorkspace\project1\src\project1, not that long I think @mousetraps It's not web tool, I didn't use any tool other than VS2015 itself and ntvs |
@billti I think express plugins' dependency hierarchy is usually bit deep, maybe that's reason how the path is so long |
@mousetraps This is the area where we may be creating this watcher: https://github.com/Microsoft/nodejstools/blob/master/Nodejs/Product/Npm/SPI/NpmController.cs#L252 . Edit: Though from the crash looks like a VS provided directory watcher, whereas the above creates a .NET one directly... so maybe not). @alanpurple Any idea how deep? (I'll knock up a quick script to grab it if unsure) |
@alanpurple sorry for not being totally clear there. web tools is a component installed with VS2015, and I'm thinking they may have introduced a bug with their own npm integration that conflicts with ours. Can you try opening up Options > Projects and Solutions > External Web Tools, and unchecking all of those boxes under "locations of external tools" as shown below, restart VS, and see if that helps work around the crash? |
@billti like this |
@mousetraps I'm trying now, but I need gulp, git, and many things. anyway I'm trying right now, and VS got too slow, it take times. |
@mousetraps yeah, tested, same and I need them also |
FYI: Below PowerShell line, run from the root of the project, will report the longest filepath
It would be useful to see what the longest path is. |
@billti mongoose is the longest 259 that powershell couldn't even search them all, it got error because it's too long maybe it's the only way that I just see and take a minute for VS to restart.....if I have to use mongodb and mongoose with Visual Studio |
Yeah, once you add in the null terminator... I think the limit it 256. Can you try moving from 'F:\VSWorkspace\project1\src\project1' to 'F:\src\project1'? Sounds like that should just squeak under the line. |
@billti F:\VSWorkSpace\project1\src\project1BE is my backend part, and I doubt if it can make any difference since mongoose module has almost infinite hierarchy length okay, at least I can try |
@billti |
Hmmm, weird. I think we'll need to actually see the exception details to figure out what file path is causing this (as based on the move above, it shouldn't be anything under the Node project location). Are you able to get your instance of VS ready just before the repro, then launch another instance of VS as an Admin (either right click/run as admin or launch devenv.exe from an Admin prompt). From the Admin instance select 'Debug / Attach to Process', then from the dialog select the other Devenv.exe instance, ensure "Attach to" is 'Managed code', and then 'Attach'. If you then go back to the instance and repro the crash, the Admin instance should catch and break on the exception. If you expand the exception object (i.e. from the Autos or Locals window or some such) the exception should have additional details attached (such as file path causing the exception, maybe an inner stack, etc...). Sorry for the trouble. Thanks for helping get to the bottom of it. |
stopped happening, after iojs 3.1.0 and mongoose 4.1.3. I don't know how, and why |
Thanks for the update. Did you update both of those at the same time and the issue went away (i.e. you are still using the same install of VS & Node Tools, but just updated those packages)? If you can detail what version of io.js/NodeJS & Mongoose you had previously when the error was occurring I'll try one last time to get a repro here. |
@billti I'm not 100% sure but it might be after iojs3.0.0->iojs3.1.0 |
Guys, there is an issue at the |
I encountered a similar problem when I converted an old node app based on the follows environment. Windows Server 2012 R2 I narrowed the scope and found that the crash came from gulp modules when saving package.json file. The difference was that my VS 2015 was thoroughly crashed and without a chance to figure out what happened. I tried to repair and even reinstall VS 2015, crash was the same as before. I have to use Acronis backup to restore the while operation system which including VS 2015, but I'd better not use NTVS 1.1 rc anymore, until the formal version released and to see if it would be ok. |
@paxibay What version of Node were you using? See the few prior comments where updating resolved the issue? If that's not the case, see the few comments prior to that and see if you might be hitting MAX_PATH issues due to folder layout. If VS is crashing that's no good though. Please see if there is an event in Event Viewer that contains a call stack we can look at. (Also, on the releases page your find NTVS RC2 which fixes a few issues and works with npmv3, which might also be an option if it is a MAX_PATH issue). |
Moving out of current milestone until we get more info to help track down. |
Just ran into this as well after
|
Visual Studio 2015 used to crash all the time for me when I did This is fine for my machine which has a Intel Core i5-4690 @ 3.5 GHz, 32 GB of RAM and a couple of new, fast SSDs. Not sure how well it works on lesser machines. |
I ran into this today as well, and managed to attach a debugger. Here's a stack trace with line numbers:
But what's interesting is that there's actually a MAX_PATH "check" in I reproduced this on the release builds of VS, so some of the code is optimized away, and I can't verify that the string does indeed have these properties, but the trace and src code is clear enough to go by here. We'll chat with the team responsible, so hopefully it can be fixed in Update 1. |
Thanks all for reporting this! The fix for this issue will be available in VS Update 1 when it's released (not available in the Update 1 RC bits that were released today, though.) |
We have had this issue for 2 years on our build server that uses gulp tasks with node. the path is way way too long. node can create the files, but nothing in .net can clean them up. We found a .net dll that wrapped the win32 file tools. we would use that in our build to delete the dev tools after the build was complete or else tfs would not be able to delete the long file path, and our build would break consistently. |
@patrickrobbins You can also use .net to run the rimraf CLI. |
April 2016. VS2015 Update 2, the bug is still here... |
Very frustrating. VS2015 Update 2 too... it is impossible to work with it... i have moved to other IDE. |
May 2016: VS 2016.Update 2.1 still having the same problem. Editing any JSON file would freeze Visual Studio after a while. Two things made it much, much better: Disabling the "(DevEnvDir)..." folders in "External Web Tools", (because I already have nodejs installed) and disabling Schemavalidation in "Text Editor/JSON/Schema" Maybe this helps someone. |
This seems to be a problem with ASP Web Tools and not NTVS. We've reached out to the Web Tools team to let them know about the problem, and there is already a bug tracking the issue: aspnet/Tooling#219 (comment) Thanks. |
windows 10 pro x64
vs 2015 enterprice
nodejstool 1.1 rc
iojs 3.0.0
python 2.7.10 x64
node-gyp in iojs 3.0.0 is intalled globally
stop working -> restarting
The text was updated successfully, but these errors were encountered: