- name: netcoredbg
- description: The NetCoreDbg debugger implements GDB/MI and VSCode Debug Adapter Protocol in a unified framework, allowing the debugging of .NET apps under the .NET Core runtime as well as facilitating debugging from the command line (such as in GDB).
- snapcraft: netcoredbg-snap/snap/template.snapcraft.yaml at main · canonical/netcoredbg-snap · GitHub
- upstream: GitHub - Samsung/netcoredbg: NetCoreDbg is a managed code debugger with GDB/MI, VSCode DAP and CLI interfaces for CoreCLR.
- upstream-relation: No direct relation. I work as a maintainer of the .NET toolchain in the Canonical Toolchains/Foundations team. I am creating a snap package for the
netcoredbgdebugger as part of my work. There is also an open request to transfer ownership of this snap to Canonical. - supported-category: debug tools
- reasoning:
netcoredbgis a debugger for .NET applications that works similarly to GDB in CLI mode and can also be connected to VSCode through its Debug Adapter Protocol. It can either spawn an application in debug mode or be attached to a running .NET process. Also, the .NET runtime installed in the machine, wherever it may be in the file system, needs to be visible tonetcoredbg. Considering these aspects, and the fact that we can’t predict what a spawned .NET app is meant to access, strict confinement is not viable.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap to work under strict confinement.
