New Release of PowerShell Extension For Visual Studio Code

There’s a new version (0.4.0) of the PowerShell extension for Visual Studio Code out with some really nice enhancements.  There’s also a new version of Visual Studio Code (0.10.8) out with lots of improvements as well (read about those here).  I encourage you to pick up both!  If you don’t already have VSCode or the PowerShell Extension, see my blog post on Getting Started with Visual Studio Code for Use with PowerShell.  If you already have these, be sure to check for updates on both.

The enhancements to the PowerShell extension fall into two different categories: editing enhancements and debugging enhancements.  There are also some new features and bug fixes in the new version of Visual Studio Code that enable a number of the new features discussed below.  So make sure you update to the new version of Visual Studio Code!

Editing Enhancements

Auto-completion lists have been improved in several ways.  First, paths used to complete like this:

The full path was displayed in the drop down list and once the path started getting long, the completion list items started to get clipped leaving you wondering what you were going to get when you selected a clipped item.

Now paths auto-complete the same way they do in PowerShell ISE.  Only the current directory’s contents are listed.  BTW I have a enhancement request into the VSCode project to provide a folder icon in addition to the built-in file icon.

PowerShelll command parameter completion used to get sorted lexicographically by VSCode.  Note the common parameters intermingled command-specific parameters (and lack of parameter type info):

In the updated PowerShell extension, we get the same sort order as you would see in ISE (plus the type info).  This is preferable because most of the time you’re interested in the command-specific parameters.

Completion lists for PowerShell commands also get improved by giving more info about the command, such as which command an alias resolves to or the path for an exe e.g.:

We also spent a good bit of time on improving the built-in snippets.  The snippets by default are productivity oriented and not teaching/example snippets e.g.

We still have the teaching/example snippets but they all start with “ex-“ e.g.:

PowerShell MVP Doug Finke added several new editor commands: Open file in ISE and find module.

Debugging Enhancements

Fellow PowerShell MVP Adam Driscoll added support for a 32-bit (x86) debug host.  The default debug host runs as a 64-bit process on 64-bit Windows and as a 32-bit process on 32-bit Windows.  The PoweShell x86 debug host always runs as 32-bit on 64-bit Windows.

In 0.3.1, when you opened a folder where you hadn’t debugged before you would press the little “gear” icon in the VSCode debug window, you would select the “PowerShell” debugger.  Now you will have two options to select from: “PowerShell” and “PowerShell x86″.  Once you select the debug host, VSCode will generate a .vscode directory in your workspace folder and then generate a launch.json file into that folder.  The file used to contained this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "request": "launch",
            "program": "SET_SCRIPT_FILE_PATH_HERE.ps1"
        }
    ]
}

In 0.4.0 it will look like this:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "request": "launch",
            "program": "${file}"
            "args": [],
            "cwd": "${file}"
        }
    ]
}

There several new features to point out in the updated launch.json file.  Note: if you have an existing launch.json file, you can add the new parameters and values.  And if you want to use the 32-bit debug host, change the “name” and “type” params to “PowerShell x86’’.  If you would like to switch between both 32-bit and 64-bit debug hosts, modify your launch.json to the following, which will allow you to select either “PowerShell” or “PowerShell x86” from the VSCode Debug view toolbar:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "PowerShell",
            "type": "PowerShell",
            "request": "launch",
            "program": "${file}"
            "args": [],
            "cwd": "${file}"
        },
        {
            "name": "PowerShell x86",
            "type": "PowerShell x86",
            "request": "launch",
            "program": "${file}"
            "args": [],
            "cwd": "${file}"
        }
    ]
}

You no longer have to specify the file to launch in the debugger via the “program” param.  By default the value of “${file}” will cause the file in the active editor window to be launched by the debugger.  This value has to be an absolute path.  This behavior is like PowerShell ISE’s behavior and is much more convenient.  However if you have say a readme.md active, it will try to debug that with PowerShell and fail.  If you want to specify a script to always start for a workspace no matter which editor window is active,  you can specify an absolute path to the “program” param.  You can use the ${workspaceRoot} variable to refer to your workspace root directory.

You can now pass arguments to your script by modifying the “args” parameter.  You can specify a single string like so:

"args": [ "-Path C:\\Users\\Keith *.ps1 -Recurse" ]

You can also break up the parameters into different strings if you prefer. In the debug host, they will be concatenated using a space delimiter into a single string:

"args": [ "-Path", "C:\\Users\\Keith", "*.ps1", "-Recurse" ]

In the previous version of the extension the debugger would start using the install directory of Visual Studio Code as the working dir.  Not very helpful.  In the new version, the launch.json file is configured to configure the current working directory “cwd” in the debug host as the parent directory of the file that is in the active editor pane.  This is usually the parent folder of the script that is launched (assuming the “program” param is still set to “${file}”).   You can modify this to any absolute path you want.  Again to reference the workspace root directory you can use ${workspaceRoot} in your cwd path.

There is a different view for the Debug Console in VSCode 0.10.8 that is wider than taller.  We had problems with PowerShell output (F8 and commands executed from the Debug Console prompt) wrapping at 80 chars.  That wrap limit has been upped that to 120 so the output should look better.   We’ve also fixed output formatting in general so you shouldn’t see much default output with “\r\n” in it.

The VSCode team made the following change which required no work on our part – we got this feature for free!  Check out the highlight on the variables whose values are changing as I step through this code:

There are some other miscellaneous debugging improvements.  We fixed a bug where you couldn’t set a breakpoint on files with [ ] chars in the path.  We also added support for supplying input to Read-Host via the Debug Console input prompt.  For more information on general debugging improvements in the new version of Visual Studio Code, check out this site.

There you have it.  We are very excited about this release of the PowerShell Extension for Visual Studio Code.  Give it a try and please let us know if you run into any issues.