Samsung / netcoredbg

NetCoreDbg is a managed code debugger with MI interface for CoreCLR.
MIT License
743 stars 98 forks source link

Support for launchSettings.json related options in DAP launch request #163

Open DRKV333 opened 4 months ago

DRKV333 commented 4 months ago

There were some other similar issues about this this topic, but I feel like those were entirely clear about the situation.

The Microsoft .NET debugger supports reading some debug settings from a launchSettings.json file. Specifically application URL, command line arguments and environment variables. This behavior of the DAP launch request configuration is documented here: https://code.visualstudio.com/docs/csharp/debugger-settings#_launchsettingsjson-support

It would be nice to also have support for this in netcoredbg. This feature exists in vscode to provide interoperability with Visual Studio, which reads this same file. The dotnet command line tool also supports launchSettings. I would also personally like to use launchSettings to keep things like command line arguments out of my main launch.json, since I don't want to check them in to source control.

The launch configuration contains two properties to control the launchSettings usage, launchSettingsFilePath and launchSettingsProfile. As far as I can tell, these are currently ignored by netcoredbg. launchSettingsFilePath determines where the json is, but defaults to {cwd}/Properties/launchSettings.json. launchSettingsProfile determines which section from the json file should be used, and defaults to the first one with "commandName": "Project". This way the launchSettings file usage is enabled by default, so implementing this exact mechanism here would also unfortunately be a behavioral change.

viewizard commented 4 months ago

launchSettings.json looks like related to parameter for dotnet run https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run, not really sure how debugger should support it.

Note, https://code.visualstudio.com/docs/csharp/debugger-settings#_launchsettingsjson-support is about VSCode IDE configuration for setup debug session, not about debugger configuration itself. VSCode IDE just provide envs and form proper launch command by this configs and send it to debugger by protocol https://microsoft.github.io/debug-adapter-protocol/specification.

DRKV333 commented 4 months ago

Ideally the debugger should support it around here: https://github.com/Samsung/netcoredbg/blob/27606c317017beb81bc1b81846cdc460a7a6aed3/src/protocols/vscodeprotocol.cpp#L565-L590 By reading the contents of launchSettings.json and passing on the args and env.

The configuration I've linked really is about the configuration of the debugger itself. The DAP specification says that in the launch request "additional attributes are implementation specific", and these are the implementation specific attributes that the Microsoft debugger uses. In fact, as far as I can tell, all of the attributes in launch.json are sent directly to the debugger in the request.

viewizard commented 4 months ago

My point was about - are your sure this is DAP related, but not IDE side related? Are you sure, that VSCode IDE form launch request with additional attributes? Could you please provide VSCode IDE <-> VSCode debugger protocol log with this feature enabled?

viewizard commented 4 months ago

You should be able to enable protocol logging in launch.json with:

            "logging": {
                "engineLogging": true
            },

for example: https://github.com/Samsung/netcoredbg/issues/155#issuecomment-1879644599

DRKV333 commented 4 months ago

So, this was quite interesting. I have a launch configuration like this:

launch.json ``` { "name": ".NET Core Launch (console)", "type": "coreclr", "request": "launch", "preLaunchTask": "build", "program": "${workspaceFolder}/src/app/bin/Debug/net5.0/app.dll", "cwd": "${workspaceFolder}/src/app", "launchSettingsFilePath": "${workspaceFolder}/launchSettings.json", "launchSettingsProfile": "TestProfile" } ```

And by enabling DAP message logging in settings, vsdbg prints this launch request:

Launch request ``` { "command":"launch", "arguments":{ "name":".NET Core Launch (console)", "type":"coreclr", "request":"launch", "preLaunchTask":"build", "program":"E:\\free-vscode-csharp\\test\\integrationTests\\testAssets\\slnWithCsproj/src/app/bin/Debug/net5.0/app.dll", "cwd":"E:\\free-vscode-csharp\\test\\integrationTests\\testAssets\\slnWithCsproj/src/app", "launchSettingsFilePath":"E:\\free-vscode-csharp\\test\\integrationTests\\testAssets\\slnWithCsproj/launchSettings.json", "launchSettingsProfile":"TestProfile", "__configurationTarget":6, "stopAtEntry":false, "justMyCode":true, "requireExactSource":true, "enableStepFiltering":true, "logging":{ "exceptions":true, "moduleLoad":true, "programOutput":true, "browserStdOut":true, "elapsedTiming":false, "threadExit":false, "processExit":true, "engineLogging":false, "diagnosticsLog":{ "protocolMessages":false, "dispatcherMessages":"normal", "debugEngineAPITracing":"none", "debugRuntimeEventTracing":false, "expressionEvaluationTracing":false, "startDebuggingTracing":true }, "consoleUsageMessage":true }, "suppressJITOptimizations":false, "symbolOptions":{ "searchPaths":[ ], "searchMicrosoftSymbolServer":false, "searchNuGetOrgSymbolServer":false, "cachePath":"", "moduleFilter":{ "mode":"loadAllButExcluded", "excludedModules":[ ], "includedModules":[ ], "includeSymbolsNextToModules":true } }, "allowFastEvaluate":true, "internalConsoleOptions":"openOnSessionStart", "__sessionId":"a623e3bd-d1fc-4e86-87f2-58337ad12fbe", "args":"This is from launchSettings" }, "type":"request", "seq":2 } ```

The args from launchSettings.json are in there, but they are sort of weirdly at the end. Also protocolMessages is set to false, even though it's very obviously enabled, since I can see them.

So it looks like vsdbg is lying. I've confirmed this by patching the vscode C# extension to launch the debugger behind a "tee" style program, so that I can log the actual requests that were sent. And there is no args there. (And protocolMessages is true.)

I'm quite sure this launchSettings option is supposed to be handled by the debugger. I couldn't find anything in the vscode extension that would parse the file. I also don't think it's actually possible for the extension to mess with the launch settings like that.

DRKV333 commented 4 months ago

I think I've figured out what's going on. The args parameter from launchSettings is actually added by vsdbg-ui.exe, which then presumably relays everything to vsdbg.exe. After looking at the extension some more, it looks like it would be possible to do the launchSettings parsing there after all. But that is not where the Microsoft setup does it currently.

DRKV333 commented 3 months ago

Hey @viewizard, what's your final verdict on this, would you accept a PR for this feature to be compatible with how vsdbg does this? Or should I try to get it supported in the vscode extension?

gbalykov commented 3 months ago

@DRKV333 support of custom launchSettings.json can be implemented in three ways: parsing of launchSettingsFilePath file on side of netcoredbg, simply by replacing original launchSettings.json file on disk with launchSettingsFilePath in netcoredbg, or the same but from IDE/plugin side (i.e. out of netcoredbg). In first case, there're issues related to interaction with dotnet host, because it also parses original launchSettings.json. This means that netcoredbg needs to modify launch command to request dotnet to ignore original launchSettings.json (I'm not sure if such option exists), and set new options. In second and third case, there're issues with interaction with other processes (e.g. someone else tries to run the same app with dotnet without debugger, thus, it will use modified launchSettings.json, which is probably undesired).

Not sure which approach is better and whether there're any other issues, so this needs further investigation. We won't work on this feature ourselves, but contributions are welcome. If you are interested in implementing this feature using first or second approach, please open PR in netcoredbg. Thanks for your interest in this project.