Registering and loading Concord extensions on Linux .NET Core vsdbg

[madkat]

I'm trying to get my language extension to load alongside other Concord extensions under vsdbg on .NET Core for Linux. The remote process debugging works great, but without the language-specific functionality there are locals that would be nonsensical to external users. Is there a straightforward path to implementation or perhaps documentation?

It looks like there is a JSON file to map language names, language GUIDs, and vendor GUIDs in the vs2022 directory on Linux. I tried updating that and supplying my assemblies + vsdconfig, but there is not much output or error feedback that I have discovered to help guide what is working or not working.

[gregg-miskelly]

@madkat Do you already have an Expression Evaluator on Windows that you are porting to Linux? Or are you trying to create one?

In case you haven't seen it:

• Getting Logs
• EE Documentation

[madkat]

@gregg-miskelly We already have one implemented on Windows that we distribute as part of a VS extension. I think that logging topic will be a good start for trying to debug what is happening on the Linux side.

[madkat]

Quick update: I was able to get my EE built correctly, registered in the default.vsdbg-config.json, and deployed into the folder. It looks like as long as all of my deps are .NET Standard or .NET 5, it all works, which is just amazing.

Any tips for trying to get my components deployed on the Linux side? The ideal flow would be hooking into the same mechanism that deploys GetVsDbg.sh. Any insight into what is or is not extensible would be a huge help.

[gregg-miskelly]

Excellent!

Any tips for trying to get my components deployed on the Linux side?

Do you know which scenarios you are trying to support (or at least support initially)? Does your language require a runtime library that is NOT just distributed via NuGet?

XPlat scenario list --

• Visual Studio
  • WSL
  • Docker
  • Attach to Process
  • Offroad launch
  • Visual Studio Code
  • Local debugging
  • Docker debugging
  • Pipe Transport
• Visual Studio for Mac
  • Local debugging
  • Docker debugging

[madkat]

My goal for an initial release is to support Attach to Process over SSH and WSL from Visual Studio. Deployment of the user application from Visual Studio, remote starting the process, and then attaching would be the ultimate user experience, but we are starting with the minimum viable product for usability.

We do have a language runtime library distributed via NuGet, but it is not required for our EE. I would expect the runtime library to be sideloaded alongside the user deploying their application.

The big question is whether or not there is an integrated way to deploy my EE and its dependencies to .vs-debugger\vsver. It looks like attaching from VS causes the creation of .vs-debugger and executes GetVsDbg.sh. Is any part of that extensible?

[gregg-miskelly]

For attach to process, I can't think of a way to make this work automatically today. I would suggest filing a suggestion ticket (Help->Send Feedback->Suggest a Feature) to provide an extensibility point for this. The best work around I can think of in the mean time is just to provide users with a script and instructions (example: https://github.com/OmniSharp/omnisharp-vscode/wiki/Attaching-to-remote-processes#installing-vsdbg-on-the-server).

For WSL: Since this scenario involves a project system, there might be a way to somehow know that debugging was about to start for WSL. I am assuming you have some sort of project system customization already?

CC'ing @NCarlsonMSFT who knows far more than I do about how the WSL integration works.

[NCarlsonMSFT]

@madkat are you interested in supporting attaching to a running process in WSL or the WSL launch profile command? If the latter, there is currently no explicit extensibility mechanism for the WSL launch profile component; however, there are extensibility points in the projects system where you could potentially prepare the WSL distro before debugging started. Let me know if that's the interesting scenario and if so I can point you in the right direction.

[madkat]

@NCarlsonMSFT Very interested.

[NCarlsonMSFT]

If you own the projects (or a common NuGet) one easy way is to add a Project Capability and then implement IProjectDynamicLoadComponent to load code for handling the project.

You can then Link an ActionBlock to the ILaunchSettingsProvider's SourceBlock. In the ActionBlock you can then track if the active profile is one that you should handle and if so, prep the default (or selected) distro for debugging.

[madkat]

@NCarlsonMSFT I really appreciate the additional information. That should give us a good starting point.