PowerShell for Visual Studio Code August 2021 Update

Andy

We are excited to announce that an update to our PowerShell extension is now available on the Visual Studio Code Marketplace. This blog will explain what is new in this release as well as what you can expect from extension updates in the coming months.

What’s new in the PowerShell Extension release

This release includes the near-completion of the CI/CD Infrastructure Project. While our release cadence already doubled over the past six months, the final major piece of this effort is complete: with PRs #3461 and #1528 (among others) the release process has been fully automated.

This means that we can now release the extension any time we like and spend more time building features and fixing bugs! The release process and versioning scheme are fully documented, but in short:

  1. A maintainer (me) invokes the New-Release function from the revamped ReleaseTools module and supplies the new version numbers.
  2. The module queries GitHub for all merged Pull Requests since the last release and auto-generates the CHANGELOG entry, complete with emoji, links to closed bugs, descriptions of work, and thanks to contributors.
  3. The module automatically increments every required version number field in both projects, including tertiary information such as the preview flag, description, and icon (which now differs for the stable and preview channels). This prevents the recurrence of bugs where our versions were mismatched, or the stable extension was marked as “preview” in the marketplace.
  4. The module automatically pushes the release branch to GitHub for both repositories with these changes and opens a Pull Request for the next release.
  5. A maintainer (me) reviews the changelog and when satisfied with any edits, pushes the release branches to our internal Azure DevOps mirrors.
  6. This push kicks off Azure Pipelines which complete the rest of the process: PowerShell Editor Services is built, tested, and signed. The ReleaseTools module is used by the pipeline to create a draft GitHub release with the signed bits directly uploaded from the secure build agent. The completion of this pipeline triggers the PowerShell Extension’s pipeline and supplies it with the signed Editor Services bits. This pipeline similarly builds, tests, and signs the extension. The module is then used again to create its draft GitHub release, and then waits for manual approval.
  7. Finally, after manual verification of the extension, a maintainer approves the final deployment step of the pipeline, which automatically uploads the extension to the Visual Studio Code Marketplace directly from the build agent (it also publishes our Install-VSCode.ps1 script to the PowerShell Gallery).

A key improvement is that last step, where the published bits come directly from the secure build agents. Previously, a maintainer had to download the bits to their development machine and then upload them manually to all the release locations (GitHub, VS Code Marketplace, PowerShell Gallery). It is well known that the introduction of a developer’s machine into this workflow is a key point of security failure. Eliminating this step took a herculean effort to coordinate updated build pipelines that automated each step perfectly, moved the pipeline assets along only after signing and verification, ensured that each pipeline used and recorded the correct sources and bits, and asked for just enough manual approval for verification.

In addition to this CI/CD Infrastructure work (which frankly took the bulk of our time), I’d like to highlight several other improvements:

  • Our extensions’ icons are refreshed to match those of PowerShell 7, with the preview channel having its own special preview icon.
  • PowerShell Editor Services is getting cleaned up: the .NET Code Analyzer was updated and many warnings were completely fixed and then marked as errors to prevent re-introductions.
  • A major source of bugs with PSReadLine has been resolved by forcing PowerShell Editor Services to load only its bundled modules. Advanced users can still beta test updated versions of bundled modules (such as PSReadLine and PSScriptAnalyzer) through the powershell.developer.bundledModulesPath setting, but for the vast majority of users the extension is more likely to just work as expected.

For the full list of updates please refer to the changelog.

What’s next for the extensions

Our upcoming work includes:

  1. The completion of the Editor Services Pipeline project, which will simplify our threading model and reduce the issues caused by race conditions and deadlocks.
  2. The related Debug Reliability project which turns out to be mostly caused by threading deadlocks.
  3. And finally the VS Code Compatibility project where we are trying to get the extension up-to-date with the editor’s best practices and newest features.

You can track the progress on all of these projects, and others on our roadmap, in our GitHub repository.

Getting support and giving feedback

If you encounter any issues with the PowerShell extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Andy Schwartzmeyer with collaboration from Rob Holt, Sydney Smith, and others.

PowerShell Team

1 comment

Leave a comment

  • Fleet Command

    Well, thanks a lot, Andy! ๐Ÿ˜Š And thanks a lot, Rob, Sydney, and unnamed others. ๐Ÿ˜˜

    I can no longer remember the bad old days when I didn’t have PowerShell!

    Recently, I’ve been thinking about expanding my PowerShell projects, but I’ll need better development tools. I need to develop self-contained scripts, but I also need to take advantage of code reuse. Maybe I should develop a build system that converts scripts with external dependencies to self-contained scripts. Anyway, that’s where I am right now. To think that I didn’t know PowerShell 12 years ago…