VSCode is no longer supporting specifiying a commandId in the "initialConfigurations" contribution

[isidorn]

Hi,

We noticed your extension in package.json is using a "initialConfigurations" contribution in a deprecated way by specifiying a command id.
We wanted to let you know that we plan to delete support for this specific use of "initialConfigurations" soon.
More about this deprecation can be found here and in our release notes.
A good example on how to use the DebugConfigurarationProvider which is the new way of doing this can be found here

Kind regards,
Isidor from the VSCode team

[gep13]

@isidorn thank you for raising this, we were initially tracking this here: #54, but I will close that one as a duplicate.

[gep13]

@isidorn would you be in a position to provide some help with this? I am trying to implement the DebugConfigurationProvider but neither the provideDebugConfigurations or resolveDebugConfiguration methods are called. At which point should I expect these to be called in order to return my initial configurations? Thanks!

[gep13]

@isidorn actually, I think I have figured this out, as we are not using the full API surface. Could you please verify the changes in this PR: #62

Thanks in advance!

[isidorn]

@gep13 I suggest that you simply try your extension against the latest vscode insiders. If it works then I would be confident of the changes.
I glanced through your code in the PR and I do not see any implementation of the DebugConfigurationProvider which I find strange.

[gep13]

@isidorn thanks for taking the time to look at this! I really appreciate it!

I have ran the code in the Insiders build of code, and it seems to work as I would expect it to.

This extension doesn't actually add anything other than the contents of the launch.json file. This comes in two forms, i.e. when the user presses F5 when there is no launch.json file in the workspace, it provides an initialConfiguration for either Cake CoreCLR or Cake Mono. If there is already a launch.json file, then we provide some configurationSnippets to allow them to add a new entry for either of the above.

And that is it. We aren't doing anything else as the configuration are either simply shelling out to the coreclr or mono debugger, neither of which are provided by this extension.

As a result, I didn't seem to need to implement the DebubConfigurationProvider, as both of these items can be provided via the packages.json file.

Does that make sense, or have I done something silly?

[isidorn]

@gep13 if it works fine then all is good. DebugConfigurationProvider is there only if you need to specially massage the launch.json configurations. If everythign works nicely staticly then just leave it as a contribution in package.json

[gep13]

@isidorn ok perfect, in which case, I think we can leave it as is, as we don't do any special handling of the launch.json (or at least, not yet 😄).

Thanks again for reaching out on this issue!