remove support for 'startSessionCommand' contribution

[weinand]

With the introduction of the resolveDebugConfiguration method on type DebugConfigurationProvider in the debug API, it is no longer necessary to contribute a startSessionCommand on the debuggers contribution point. Therefore we are deprecating the startSessionCommand in this milestone and plan to drop it in October 2017.

[isidorn]

ping @roblourens since we have now removed support for the startSessionCommand so it would be great if chrome adopts this change and starts using DebugConfigurationProviders. There are great examples in the Mock Debug in Node Debug

[DonJayamanne]

The startSessionCommand command provided the ability to debug even without having to open a workspace.
I have now adopted the DebugCOnfigurationProvider and registered it, and when testing debugging of a simple python file (in the python extension) I don't get what I expect.

The resolveDebugConfigration method is invoked and the provideDebugConfigurations is not.
Also, the debugConfiguration object passed into the resolveDebugCOnfiguration method is an empty object.

Is the solution for me to check if it's an empty object and then inject the other properties that would be required by my debugger?

Or am I missing something in my workflow/implementation?

[weinand]

@DonJayamanne yes, checking for the empty object is a correct approach. It has not changed from the now obsolete startSessionCommand approach.

provideDebugConfigurations is only called if a new launch.json needs to be created (which is not the case when you just want to debug a python file from the editor with F5). This behaviour has not changed with the introduction of the DebugCOnfigurationProvider.

See what we do in node-debug: https://github.com/Microsoft/vscode-node-debug/blob/ae3618de23acc4ce6e81a5d65e56ed76f9ef69da/src/node/extension/configurationProvider.ts#L34

[isidorn]

fyi @daviwil @rkeithhill @delmyers @gregg-miskelly @MSLaguana @DanTup @devoncarew @WebFreak001 @andysterland @hbenl @lukaszunity @svaarala @ramya-rao-a @vadimcn @felixfbecker @MSLaguana @rebornix

We have removed quite some depricated debug commands since they now have nice debug API alternatives. This is documented in our release notes and here are the issues covering that.

[gregg-miskelly]

@isidorn the new debugging API was introduced in the August release (that shipped in early September) and the old API will be removed in the October release (which ships in early November). Is that correct?

[isidorn]

@gregg-miskelly correct

[DanTup]

@isidorn Thanks; I'm hoping to work on this this weekend - hoped to have done it already!

Are the APIs already removed in insiders?

[isidorn]

@DanTup yes, in insiders the command support is already removed

[testforstephen]

In the latest vscode-insider (2017-10-11), if no launch.json file exists in current workspace, click F5 and it seems nothing happens. Is there any possible to pop up the Add Configuration dropdown menu to guide user?

Another issue is that when a previous debug session is still on starting, click F5 again will cause duplicated debug sessions for the same debug configuration.

For example, the first activation of the java debug server may cost several seconds to start up. During this period, if user clicks F5 for several times, VSCode will launch duplicated debug sessions for the same debug configuration.

Can VSCode client have the possible to fix it? or passing a configuration id for the selected debug config in the API resolveDebugConfiguration so that the debugger can check duplicate by itself?

[isidorn]

@testforstephen please create a new issue for this where we can discuss this further. Thank you

[testforstephen]

@isidorn sure. open two new issues for this.
#36045
#36044

[DanTup]

I think I've managed to move over from this, but when converting from startSessionCommand (which used to take a FlutterLaunchRequestArguments, a sub-class of DebugProtocol.LaunchRequestArguments) I had to put this nasty cast in so I can read/write the launch arguments:

resolveDebugConfiguration(folder: WorkspaceFolder | undefined, debugConfig: DebugConfiguration, token?: CancellationToken): ProviderResult<DebugConfiguration> {
	this.setupDebugConfig(<FlutterLaunchRequestArguments><any>debugConfig);
	// ...

The only other examples I found using this all just index into the DebugConfiguration but I really want to stick with my nice types. Is this cast a good way to do it, or have I done something bad? (It does appear to work).

[isidorn]

Shouldnt FlutterLaunchRequestArguments extend from DebugConfiguration at the end?
Not sure how to make the types flow nicely, but at the end DebugConfiguration is just the required part of the configuraiton that the vscode is aware of. Debug adapters are aware of additional fields on top of the basic ones.

[DanTup]

I did try that, but then I just errors at the other end because my DebugSession's args property was no longer a LaunchRequestArgs:

export class DartDebugSession extends DebugSession {

I'ts not obvious to me if there should be a relationship between DebugConfig and DebugProtocol.LaunchRequestArguments.. one is being built at the Code side and the other being passed to the debug adapter, but in code they're totally unrelated.

I'll leave my cast in for now since it seems to work. Looks like other adapters might just indexing into the object with string keys so they don't see this (but I really don't want to do that, I already have a nice class!).

[isidorn]

fyi @DustinCampbell

@rkeithhill I have only pinged @gregg-miskelly on this issue, forgot Dustin. Thanks for pointing out

[ramya-rao-a]

@rkeithhill

This makes the compat cross-over a bit tight. I mean 1.17 came out less than a month ago but when 1.18 drops we have no choice but to update to a min version of 1.17. That leaves folks who updated VSCode less than a month ago, not able to debug with the latest PowerShell extension (until they update VSCode).

As far as I understood extension updates, an update with engine version set to say 1.17 will not even show up as an update to someone using VS Code 1.16. They will never get the extension update until they update VS Code. So they should be able to debug just fine.
@sandy081 can confirm this.

[sandy081]

Yes, we only install the compatible extensions for the given VS Code version by checking their engine property.