Solution Explorer crashes when renaming/moving/copying/deleting files

[thomas-darling]

The Solution Explorer for ASP.NET 5 MVC projects has several major problems - one of them is that it hangs the whole IDE when a large number of files are changed/renamed/moved/copied/deleted - another is the fact that the project system constantly crashes, gets out of sync with the file system, and if the project is not immediately unloaded and reloaded, often the whole IDE. Those issues affect Visual Studio 2015 Update 1 with ASP.NET 5 Release Candidate 1 and have been reproduced on three different machines - two running Windows 7 and one running Windows 10.

Those bugs occurs so often (multiple times per day), that I am literally giving up on Solution Explorer, and instead perform many of my rename/move/copy operations using Windows Explorer, usually with the project unloaded to make sure it doesn't blow up. This is a nightmare, guys - it makes Visual Studio impossible to work with.

This is an example of what it looks like:

In this case I reproduced it by using ctrl+drag in Solution Explorer to create a copy of the "search" folder, and then tried to rename the resulting "search - Copy" folder to "foo". This failed with the error message shown and left me with what appears to be an extra, non-existent "foo" folder. Trying to delete this non-existent folder then caused the the project system to crash, forcing me to unloaded and then reload the project to recover - as failing to do that often causes the whole IDE to come crashing down soon after.

Another equally common and critical example of this bug occurs when moving or deleting files and folders in Solution Explorer, especially large folder trees - here the operation often fails and/or leaves "ghost files" that cannot be deleted without crashing the project system or the whole IDE.

The following is examples of the logs resulting from errors like the ones described above, although I'm not sure exactly which ones are related to those - I think a couple of them may be from crashes caused by things like updating npm or jspm packages or moving/deleting files using Windows Explorer...
VsProjectFault_5f087ed7-0323-459a-a076-a4e3c9e2f172.failure.txt
VsProjectFault_7329c104-0933-41a9-8092-44be0880358e.failure.txt
VsProjectFault_a5a7e760-0e8a-4a11-98b5-ce0840bf5204.failure.txt
VsProjectFault_a324f366-003b-4ced-93e2-80ed6df55f52.failure.txt
VsProjectFault_c8f111a8-5a3f-4183-8932-e943b7bfad1e.failure.txt

Note that in some of those logs, I have removed the content below "PRIOR tree:" as it was very large and reveals details of our solution. I can provide the original logs upon request.

[abpiskunov]

It would be great if you also collect dumps when you see VS crashing during files manipulation. Attach to crashed VS and then in Debug menu click on Save Dump As ... Please zip them and attach to this issue.

[abpiskunov]

Also if possible attach zipped solution so CPS team could quickly reproduce scenarios you describe here.

[abpiskunov]

Hm I am looking at stack traces and they all happen in very different places. Some in our code some in CPS. Do you remember which stack trace was collected for what scenario? We need to know it otherwise it might be hard to reproduce..

[abpiskunov]

TFS 175053

[thomas-darling]

I'll see what I can do :-)

I'm 90% sure VsProjectFault_7329c104-0933-41a9-8092-44be0880358e.failure.txt was the one produced as a result of the rename bug described in the issue - the other ones are just a few examples of other crashes I've seen in the last few days.
I'm not sure the "ghost files" issue actually produces an error log, as it doesn't technically crash - it just ends up in a really bad state that, if the project is not immediately reloaded, does eventually result in an error or crash, e.g. if you try to delete those ghost files.

[abpiskunov]

FYI when you see ghost files or folders in the tree, it means tree has invalid state obviously, and it might produce crash at any point in different stack traces.. So my guess is most crashes you saw were caused by incorrect tree state, but(!) :) please still note down after what scenario crash happened with dumps and was tree state wrong at that moment or not when possible ...

Thanks for helping us to narrow it down!

[thomas-darling]

Yep, I'll try to collect some additional info on this when it happens, and I'll also see if I can get you a good project for reproducing it more consistently - thay may be after christmas though, as I've technically been on vacation for a few days now :-)

I should maybe also mention that I've seen those issues in several different projects. We've been doing a lot of prototyping to evaluate various approaches to folder structure for a large app that will have lots of client-side code, and it appears the problems get worse the larger/deeper the folder trees get, which easily happens when experimenting with e.g. a "nested components" structure for the client code.

Also, while those issues do happen very often, they don't happen consistently - i.e. if a move of some files left behind ghosts, then I can sometimes move the files back to where the ghosts are, and then redo the same move again, this time without seeing ghosts left behind. Also, sometimes only a few of the files are left behind as ghosts, not all of them.

To me, this kinda feels like either a file-locking or concurrency issue, where the risk of hitting it just increases with larger folder trees - but of course, that's a complete guess :-)

[jviau]

@thomas-darling
I am looking into this issue and have a quick question - what language is your file system?

[thomas-darling]

@jviau
Sounds good - as mentioned in the issue, this happens on both Windows 7 and 10 (didn't try 8), all using the NTFS file system, with English as system language. Oh, and I'm sorry I never got back to this issue with more details - in the interest of hitting our deadlines, we had to give up on VS, and instead moved our app to node + express and VS Code. I still hope to see this issue solved though, as it's pretty hard to let go of the VS editor and debugger :-)

[kant2002]

Something new on this issue? It is pretty annoying.

[abpiskunov]

It should be fixed in Dev14 U2 and latest WTE

[ciaran036]

It's 2017... two years have past and I'm on Update 3 of VS2015, and I'm experiencing this issue consistently every time. May actually have to give up and go back to VS2012 by the looks of it.

Doesn't matter what I do - no matter what way I attempt to add a file to the solution explorer, Visual Studio crashes.

[rezamohamed]

I'm on VS2017 Community Version 15.2(26430.12) and I still have this issue

[justmao945]

VS2017 15.8.1 also have the same problem.....