Add support for passing custom config (that isn't in launch.json) into debug adapters

[DanTup]

I'm not sure what's the best way to do this, but we have some config (the location of the Dart SDK) we'd like to pass into the debug adapter. We don't want to force the user to put this into launch.json since the extension already knows it (we detect it and/or allow the user to config it).

As far as we can see, there's no way to pass additional info into the debug adapter (if this is incorrect, great, can you point us in the right direction?) or to have it access the Code config?

For now we're discussing dumping this into a temp folder and reading it back out, but obviously that's a bit of a hack!

[jrieken]

You can use data from the settings ala config.foo.bar

[DanTup]

Oh, I figured using vscode wasn't possible (I did test and it crashed, but I was trying to show an error message via window). Is it all just the same code as doing it in the extension? Is there an obvious way to know what works in the debug adapter and what does not?

[weinand]

@DanTup a debug adapter is not running in the extension host and therefore has no access to the vscode API. The reason for this is that a debug adapter can be implemented in any language and should be independent from VS Code as far as possible. All communication between VS Code and the debug adapters is done through the protocol or the launch config. There are no hidden side channels.

I understand your need for a 'side channel' but I do not yet have a good and final solution.

What I suggest in the meantime:
In your package.json introduce a new variable 'dartSettings' that is associated with a 'command' that you can implement in your extension code (not in the debug adapter). This variable can then be used as a value in the launch.json to pass all dart settings into the debug adapter. In order to avoid that the user has to create this attribute/value pair manually, you can add it to the initialConfigurations in your package.json.
For details see section 'Debug Extension Authoring: Command Variables' in the June release notes.

[DanTup]

That's what I thought, that's why I was confused by @jrieken's comment.

The value is not known until runtime and it can be changed by the user in settings, so putting it in initialConfugration won't work.

We do have a workaround (we write into %temp%\dart-code.txt and then read it from the debug adapter) so this isn't critical, but our workaround is a bit hacky (and doesn't handle multiple instances of Code with different Dart SDK paths properly) so a better way to do this would be great.

[weinand]

@DanTup the variable's name will be put in the initialConfugration, not the value. The value is calculated in your extension just before the user launches the debug session. So this would work fine in your case and would eliminate the need to write to some temp file.

The line in the launch config would look like this:

"dartSettings": "${command.dartSettings}"

As you can see there are no concrete values visible to the user.
${command.dartSettings} evaluates at runtime to whatever your extension command returns. E.g. you can just return the dart settings the user has configured for the workspace or globally.

[DanTup]

Oh, gotcha. I'll have a play around. Thanks! 😀

[weinand]

Mock debug has a simple example where a command variable evaluates to a string entered by the user: https://github.com/Microsoft/vscode-mock-debug/blob/master/src/extension.ts

[DanTup]

Perfect, thank you! :)

[DanTup]

@weinand Looks like an update (1.10?) to Code has broken this..

"dartSettings": "${command.dartSettings}"

Now says Unexpected token $ in JSON at position 0.

I'm struggling to make this work - I tried adding \\ to the start (I saw this change and wondered if it was related).

This means as people upgrade to 1.10, launching Dart apps is broken; do you know what the correct fix is? Is there somewhere we can monitor for breaking changes like this?

[DanTup]

@weinand Never mind; the tooltip in launch.json explained the issue (the fix is changing to command:). I think maybe this one might need updating then?