Support debug apps running under mono runtime using vsdbg. #6752
Conversation
package.json
Outdated
| "pickRemoteDockerProcess": "csharp.listRemoteDockerProcess" | ||
| }, | ||
| "configurationAttributes": { | ||
| "launch": { |
There was a problem hiding this comment.
The launch and attach configurations are generated with the generateOptionsSchema script. You will want to add updating this debugger too.
vscode-csharp/src/tools/generateOptionsSchema.ts
Lines 351 to 358 in 9caecf2
There was a problem hiding this comment.
Alternatively, you could also undo the Concord-side change to LanchOptions.json, I will leave a comment in the Concord PR with more information.
package.json
Outdated
| "required": [ | ||
| "program" | ||
| ], | ||
| "properties": { |
There was a problem hiding this comment.
Do you expect users to ever use monovsdbg in a launch.json file? If not, you might not want to document the args.
There was a problem hiding this comment.
Looking at the implementation, if I understand correctly, a lanunch request is really an attach, with the 'project system' responsible for starting the target process. To me, this suggests we probably don't want anyone directly using this, so we should probably just not document any of the arguments.
There was a problem hiding this comment.
If users are not going to register anything in a schema, is it good enough to just register the DebugConfigurationProvider and DebugAdapterDescriptorFactory for monosvsdbg?
src/tools/generateOptionsSchema.ts
Outdated
| @@ -357,6 +357,9 @@ export function GenerateOptionsSchema() { | |||
| packageJSON.contributes.debuggers[1].configurationAttributes.launch = schemaJSON.definitions.LaunchOptions; | |||
| packageJSON.contributes.debuggers[1].configurationAttributes.attach = schemaJSON.definitions.AttachOptions; | |||
|
|
|||
| // Mono | |||
| packageJSON.contributes.debuggers[2].configurationAttributes.launch = schemaJSON.definitions.LaunchOptions; | |||
There was a problem hiding this comment.
I think instead we probably don't want to declare what options monovsdbg takes since we don't want people using it directly.
There was a problem hiding this comment.
Extension code changes look good, but I think we probably don't want to document the launch args for monovsdbg unless I am wrong and we want to allow folks to directly use it, in which case we probably want to filter out all the arguments that are only applicable for CoreCLR.
src/main.ts
Outdated
| @@ -425,11 +425,17 @@ function tryGetCSharpDevKitExtensionExports(csharpLogObserver: CsharpLoggerObser | |||
| ); | |||
| } | |||
|
|
|||
| let registered = false; | |||
There was a problem hiding this comment.
nit: I think we want a comment that this flag is to ensure that profferBrokeredServices is only done once.
package.json
Outdated
| "required": [ | ||
| "program" | ||
| ], | ||
| "properties": { |
There was a problem hiding this comment.
If users are not going to register anything in a schema, is it good enough to just register the DebugConfigurationProvider and DebugAdapterDescriptorFactory for monosvsdbg?
…the launch.json will be created by another extension.
…ode-csharp into thays_support_mono_debugging
thaystg
force-pushed
the
thays_support_mono_debugging
branch
2 times, most recently
from
59e62df to
f4f9f0f
Compare
thaystg
force-pushed
the
thays_support_mono_debugging
branch
from
8d28461 to
6bc5dc4
Compare
WardenGnaw
dismissed
gregg-miskelly’s stale review
Due to the holidays and unblocking Thays🎄❄️
thaystg
force-pushed
the
thays_support_mono_debugging
branch
from
ae4df7c to
2d0ea06
Compare
No description provided.