Udostępnij za pośrednictwem

Visual Studio Code - NEW FEATURES: 13 Big Debugging Updates (Rich Object Hover, Conditional Breakpoints, Node.js, Mono, & More!)

  • Artykuł

The Visual Studio Code 0.10.8 release features a palpable plethora of improvements, including...

Debugging

Rich Object Hover

We are now using a tree in the debug hover to allow better rich object inspection:

debug hover

Conditional Breakpoints

We now support setting conditional breakpoints that are hit only when the specified condition is true. Please note, the underlying debug target, such as Node.js, must support conditional breakpoints for this feature to work.

conditional breakpoints

Changed Variable Indication

We now indicate in the Debug and Watch views which variables have changed values between step events.

variables changed

Node.js Debugging

Source Maps with Inlined Source

Node.js debugging now supports source maps with "inlined source" in addition to "inlined source maps" which were already supported. To avoid confusion, here is a brief explanation of these two source map options. "Inlined source" and "inlined source maps" are orthogonal features and VS Code supports both either alone or in combination:

  • Inlined source maps:  The contents of the source map does not live in a file but is a data URL at the end of the generated file.
  • Inlined source:  The contents of the original source file does not live in a file but is included in the source map.

The strategy for which situations VS Code will use "inlined source" is as follows:

  • VS Code always tries to locate the source on disk first.
  • If it cannot find the source (e.g. because there is none in the VS Code workspace or because the paths in the source maps are broken), VS Code will use the "inlined source" if available.
  • If there is no inlined source, VS Code will fall back to get the file contents from Node.js itself.

Whenever the editor contents is not loaded from the file system but comes from the debugger backend, the editor will be in read-only mode and the "origin" of the editor contents is shown in the editor title like this:

Editor showing inlined source

Remote Debugging

The followings improvements enable VS Code to support remote debugging, includes debugging into a Docker container:

  • The attach launch configuration now supports an address attribute where a remote host can be specified. Please note that remote debugging is only supported on recent versions of Node.js (>= 4.x).
  • The attach launch configuration now supports a localRoot and a remoteRoot attribute that can be used to map paths between a local VS Code project and a (remote) Node.js folder. This works even locally on the same system or across different operating systems. Whenever a code path needs to be converted from the remote Node.js to a local VS Code path, the remoteRoot path is stripped off the path and replaced by localRoot. For the reverse conversion, the localRoot path is replaced by the remoteRoot.

launch.json relative paths not automatically converted to absolute ones

In order to achieve consistency across our configuration files, we plan for the February release to no longer automatically convert certain paths from relative to absolute in launch.json. We recommend that for the program, cwd, outDir, and runtimeExecutable attributes, you prefix your relative paths with the${workspaceRoot} variable as soon as possible. To make it easier for you to find the affected paths that need this treatment, we highlight them with a green squigglies for the January release. (Please note: since we continue to automatically convert paths for the January release, your launch configurations will continue to work).

"--nolazy" option not automatically added

In order to make sure that breakpoints are hit reliably, VS Code automatically added the --nolazy option when launching Node.js. With the advent of Node.js alternatives that do not support this option (e.g. Chakra), we've removed this automatic behavior. If you see that breakpoints are not hit reliably in Node.js applications, please verify that your launch configuration sets the --nolazy option explicitly via theruntimeArgs attribute.

Mono debugging

Support for VS Code Debug Console

For VS Code Mono debugging support, we've added an externalConsole attribute, which controls whether the Mono target application is launched in an external console or in the built-in Debug Console (the default). Please note that the built-in Debug Console does not support keyboard input for your application.

Workbench

Horizontal panel

We now show the debug consoles horizontally:

Horizontal output panel

Extension Authoring

Debug Protocol Changes

We have changed the debug protocol in the following (backward compatible) ways:

  • Feature negotiation: the response of the InitializeRequest now returns information about the capabilities of the debug adapter. The VS Code debugger uses this information to enable or configure features which only exist for certain debug adapters.
  • New request ConfigurationDoneRequest: VS Code sends this request to indicate that the configuration (e.g. registering stored breakpoints and exception options) of the debug session has finished and that debugging is about to start. For backward compatibility, VS Code will send this request only if the debug adapter returns a value of true for thesupportsConfigurationDoneRequest capability.
  • Additional attributes for Source type:
    • an optional origin attribute to provide additional information about the source in the debug UI.
    • an optional adapterData attribute that the VS Code debug UI will transparently persist for breakpoints.
  • New type SourceBreakpoint: an array of SourceBreakpoint is an alternate means to specify the individual breakpoints for the SetBreakpointsRequest. The SourceBreakpoint allows for specifying column and condition information for a breakpoint (in addition to the line).

Test Suite for Debug Adapters

With the January release, we've started to simplify the process of writing automated tests for a debug adapter. The basic idea is to provide a toolkit with Promise-based building blocks for individual protocol requests (e.g. stepInRequest) and for common request sequences (e.g. hitBreakpoint). These building blocks can be easily configured for a specific adapter and combined to form complex scenarios.

Here are three example Mocha tests:

 var dc: DebugClient = ...; test('should run program to the end', () => { return Promise.all([ dc.configurationSequence(), dc.launch({ program: "main.js" }), dc.waitForEvent('terminated') ]); }); test('should stop on entry', () => { return Promise.all([ dc.configurationSequence(), dc.launch({ program: "main.js", stopOnEntry: true }), dc.assertStoppedLocation('entry', 1) ]); }); test('should set a breakpoint and stop on it', () => { return dc.hitBreakpoint({ program: "main.js" }, "test.js", 15); });

More examples can be found in these debug adapter projects on GitHub:

You can see the Promise-based API in DebugClient.ts and an initial set of tests in adapter.test.ts. We plan to make this API available as an npm module in February.

Notable Bug Fixes

  • 1687: VSC 10.6 does not allow to attach debugger to running Electron app
  • 1962: Debugger fails when offline

           

     

Check out all the new features and update to Visual Studio Code v0.10.9:

https://code.visualstudio.com/updates

 

   

Have a good buy! Have a great buy.

   - Ninja Ed

Comments