The extension makes Visual Studio unstable
Closed this issue · 5 comments
- When I visualize a Bitmap then close a Windows Forms app several times, the Visual Studio UI enters in troubles.
For example it can be blank after the application is closed:
- After the previous problem, if I try to run again the application (F5), VS loops indefinitely:
Apparently, VS cannot read Program.cs again.
I can't even cancel that. I have to kill VS process.
No more problems after having uninstalled the extension.
VS : Version 16.11.4
Application : Windows Forms on .NET 5
dotnet --version : 5.0.401
Windows Update : up-to-date
Unfortunately debugging a .NET Core (including .NET 5 and newer) application may lead to several issues.
Visual Studio is running on .NET Framework, and is able to use debugger visualizers written also in .NET Framework. The interop between the .NET [Core] application and the visualizer is far from perfect. I also have reported several issues to the Visual Studio Developer Community, some of them have already been fixed but some of them are still pending.
I'm afraid I cannot provide a 100% satisfying answer here but I can share some experiences:
- You may try VS2022. It's still in preview but I didn't really experience these indefinite hangups with that. It is not perfect either, the complete debugger and the Watch window often "loses control" (especially for the first time), but then a "Step over" (F10) in the debugger usually fixes things.
- For a more stable debugging experience I suggest adding also a .NET Framework target, eg.
net48(of course, only if you don't use exclusive .NET Core features). It may be useful purely for debugging even if you release your product only for .NET 5.
Thank you for your detailed info (and for your extension, by the way).
I will try VS 2022, and wait for MS to fix their bug.
Unfortunately, I can't use the workaround of multiple targets.
I let a message on developercommunity.visualstudio.com, and I encourage readers to do the same, or at least vote.
Thanks again for your efforts.
Hopefully fixed by this commit.
VS does not really like large in-memory serializations but unfortunately it wasn't too verbose about describing the issue (and debugging the debugger itself is also really hard due to the remote app domains VS creates for visualizers). But I managed to reproduce something similar also with a Framework project that revealed that VS tends to dispose the debugged images even in the middle of the serialization to free up memory, which then causes access violation as the bitmap data is no longer valid... Now my non-Framework tests also seem much more stable.
Thank you. I imagine debugging VS for an extension can be difficult. Especially without the source code of VS.
And now VS seems to be thread-intensive, I'm not that surprised it disposes objects at any moments.
Extensions have to be very robust nowadays ! ;-)