-
Notifications
You must be signed in to change notification settings - Fork 19
Differences between Visual Studio Code and the Visual Studio Debug Adapter Host
Andrew Crawley edited this page Mar 19, 2019
·
2 revisions
Although the Visual Studio Debug Adapter Host is intended to be broadly compatible with debug adapters written for Visual Studio Code, there are some small differences that may affect some debug adapters.
- Visual Studio only supports hosting stand-alone debug adapters. Adapters which depend on Visual Studio Code's extension system, editor, or language services to launch or debug a process will not work without modification.
- Visual Studio Code allows freeform text in many fields, such as the
reasonfield on thestoppedevent. Visual Studio requires that values for enumerated fields match a value of the enumeration. Invalid values will produce a warning in the log, and may result in incorrect behavior. - In most cases, if the
successfield on a response isfalse, Visual Studio will terminate the debug session. - Any protocol messages received after the response to the
disconnectrequest will be discarded and produce a warning in the log. - Visual Studio requires all threads to enter and leave break mode at the same time. Stepping, stopping, or continuing a single thread is not supported.
- Visual Studio issues a
variablesrequest after any variable is modified or expression is evaluated while in break mode under the assumption that any evaluation could have side effects. Debug adapters should be sure that the response to thevariablesrequest always reflects the current state of the program. - Visual Studio uses 32-bit signed integers to represent
numberorintegerfields defined in the protocol. If a protocol message is received that contains a value for anumberorintegerfield that is too large to fit into a 32-bit signed integer, an error will be displayed and the debugging session will be terminated. We recommend that adapters not directly use ID or handle values received from the underlying operating system to avoid this issue. Instead, adapters should maintain a mapping between a small, opaque value used in protocol messages and the underlying OS object.
- The
idfield should be set on all breakpoints. Failure to set this field will produce a warning in the log, and may result in incorrect behavior. - The
messagefield should be set if theverifiedfield is set tofalse. This message will be shown in the UI. Failure to provide amessagefor a non-verified breakpoint will produce a warning in the log. - The
linefield must be set if theverifiedfield is set totrue. Failure to set this field will cause the debug session to terminate.
- The
formatfield is ignored. - The
widthfield is ignored. - The
labelfield is ignored.
- Visual Studio does not set the
negatefield.
- The
sendTelemetryfield is ignored. - The
showUserfield is ignored. - The
urlfield is ignored. - The
urlLabelfield is ignored.
- The
dateTimeStampfield is ignored. - The
addressRangefield is ignored.
- The
namedVariablesfield is ignored. - The
indexedVariablesfield is ignored. - The
expensivefield is ignored. - The
sourcefield is ignored. - The
linefield is ignored. - The
columnfield is ignored. - The
endLinefield is ignored. - The
endColumnfield is ignored.
- The
presentationHintfield is ignored. - The
originfield is ignored. - The
adapterDatafield is ignored.
- The only supported values for the
presentationHintfield arenormalandlabel. - If the
moduleIdfield is specified, it must match theidof aModuleobject previously provided. An invalid module ID will cause the debug session to terimnate.
- The
kindfield is ignored. - The
namedVariablesfield is ignored. - The
indexedVariablesfield is ignored. - The
evaluateNamefield must be specified in order to use the "Add to Watch" feature. Failure to set this field will produce a warning in the log.
- The value of the
idfield for amoduleevent with areasonofnewmust be unique. A duplicate module ID will cause the debug session to terminate. - The value of the
idfield for amoduleevent with areasonofremovedmust match an existing module ID. An invalid module ID will cause the debug session to terminate.
- The
variablesReferencefield is ignored. - The
datafield is ignored for events with acategoryvalue other thantelemetry.
- The
descriptionfield is ignored. The UI will reflect the value passed in thereasonfield instead. - The
textfield is ignored. - The
allThreadsStoppedfield is ignored. Visual Studio requires that all threads enter and leave break mode at the same time. - The
threadIdfield is required. Failure to set this field will cause the debug session to terminate. - The value of the
threadIdfield must match an existing thread ID. An invalid thread ID will cause the debug session to terminate.
- The
restartfield is ignored.
- The value of the
idfield for athreadevent with areasonofstartedmust be unique. A duplicate thread ID will cause the debug session to terminate. - The value of the
idfield for athreadevent with areasonofexitedmust match an existing thread ID. An invalid thread ID will cause the debug session to terminate.
- The
allThreadsContinuedfield is ignored. Visual Studio requires that all threads enter and leave break mode at the same time.
- The
exceptionIdfield must be of the formCategory/Id, e.g.CLR/System.ArgumentException. Specifying a value with an invalid format will produce a warning in the log. - The
descriptionfield should be specified, as its value is shown in Visual Studio's exception popup. Failure to set this field will produce a warning in the log.
- The
typefield is ignored. - The
variablesReferencefield is ignored. - The
namedVariablesfield is ignored. - The
indexedVariablesfield is ignored.
- The
totalFramesfield is ignored.
- The
clientIDfield will always be set tovisualstudio.
- The
titlefield is ignored. - The
kindfield must be set toexternal, or the request will fail.