How does one debug the GUI applications?

[corbob]

trafficstars

I asked @TylerLeonhardt about this on Discord, and instead of keeping it hidden in Discord where it could disappear, I thought I would bring it out here: I am not able to debug the GUI application at all. Some of the things I have tried:

• Attach to the pwsh session that is running the GUI. This doesn't seem to work at all.
• Attach to the GUI process. This doesn't allow me to set breakpoints, but it does catch the unhandled exception that's thrown when I try to copy a row (hence the need to debug). The Debug Console in VS Code gives a lot of lines similar to: Loaded 'C:\code\GraphicalTools\module\Microsoft.PowerShell.GraphicalTools\OutGridView.Gui\win-x64\System.Collections.Immutable.dll'. Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.

The provided debug configurations don't reference files that are actually produced, and thus they don't seem to work.

My intention behind this issue is to bounce ideas around of how to debug this thing, and then when we have a solution we can move it into a document within the repository so that others can benefit.

[TylerLeonhardt]

I don't think you need to turn it on... But in the "attach to .NET Core process" launch.json, you can set justMyCode to false and see what happens.

[corbob]

Well Setting justMyCode to false allows me to debug the cmdlet and step into it when attached to the pwsh session. But naturally once it passes into the new process that's where my stepping stops (even with -PassThru it doesn't enter the debugger when coming back from the gui portion.

When attached to pwsh, the cmdlet portions will set the breakpoints as available. When attached to the Gui process, all of the gui breakpoints are marked as no symbols.

[TylerLeonhardt]

So strange... The pdb files are next to the dlls for the GUI process, right?

[tig]

@andschwa This should be closed as won't fix since it's for the Avalona version.