dotnet
issue with attached debugging of a C# dll from F# polyglot
When attaching debugger to F# interactive session from polyglot specifically, hitting breakpoints results in "The application is in break mode" window, instead of hitting breakpoint normally. Note that the same works fine if using C# polyglot cells or console based fsi. If you disable "Just my code" in VStudio options than you can see some exceptions are getting hit inside Microsoft.DotNet.Interactive. I'm not sure how relevant this is. Thx, KN
Version: 1.0.522904+cdfa48b2ea1a27dfe0f545c42a34fd3ec7119074 Library version: 1.0.0-beta.24229.4+cdfa48b2ea1a27dfe0f545c42a34fd3ec7119074 Build date: 2024-06-29T19:03:08.5793733Z
- OS
- [x] Windows 10
- Frontend
- [x] Visual Studio Code
Screenshots
all attached in zip please see png issue.zip
It's surprising that this would behave differently. Both of these kernels run in the same process. It seems like there might be some difference in the way that the two different kernels load referenced assemblies and that could affect the debugger.
FWIW, the way that I typically attach a debugger in Polyglot Notebooks is like this, which saves you having to write out the PID and attach manually:
System.Diagnostics.Debugger.Launch();
I expect it is because we don't generate symbols. We can see what we can do to improve it. It would be fair to say that even under fsi the debugging experience isn't great.
Non-intuitive to me why not having symbols (I assume for F#) would impact C# debugging. One other thing I noticed that is probably not relevant but just in case... The AssemblyLoadContext usage in Interactive is quite diff between the two languages: F# is using a Default singleton, while C# creates a specialized one for every "#r".
#r nuget is directly supported by F# Interactive but not by C# Script. For this reason, the implementation for C# is in this codebase, while the F# implementation is not.