We’re proud to announce the general availability of PowerShell 7.3!
PowerShell 7.3 is built on top of .NET 7 and as a non-LTS (Long Term Support) release will be supported for 18 months.
PowerShell 7.2 is still the current LTS (3-year supported) release of PowerShell.

How do I get it?

Since PowerShell 7 is supported on Windows, Linux, and macOS, there are a variety of ways to get it.
If you had installed the previous PowerShell 7 stable release (7.2) via the Windows Store,
you will be automatically updated to 7.3 GA.
However, if you installed the MSI and chose to be updated via Microsoft Update, since 7.2 is a LTS release,
you will not be automatically upgraded to 7.3 and needs to be manually installed.

What’s new?

You can see a video of demos I presented at this year’s PSConfEU minicon.
It covers some of the major changes including new features and important bug fixes.
Lots of the work presented were contributions fromm the community!

Known issues

We found a last minute issue that should not affect most users that we will fix in an expected 7.3.1 release in December.
Due to an issue with our framework dependent package to be included with the .NET SDK Docker images,
the .NET 7 GA SDK image will still have PowerShell 7.3-rc.1 included.
This should not have any functional impact to users and we expect to update the image with PowerShell 7.3 GA in December.

Focus on the shell

The major theme for this release is focusing on making PowerShell 7 a great shell environment.
Here, “native command” means an executable that is not a PowerShell cmdlet or function.

Improvement to native command argument passing

Windows and Linux/macOS have fundamental differences in how native command arguments are handled specifically when quotes are involved.
We added a new feature $PSNativeCommandArgumentPassing
to control how PowerShell passes arguments to native commands.
The default behavior for Windows and Linux/macOS should work as most users expect in their respective environments.

Another area to make native commands work more like cmdlets is error handling.
Unlike cmdlets, native commands use their exit code to convey success or failure.

Consistency in error handling for native commands

Although stderr is often used for error messages,
it is also used for progress, information, warnings, etc. because native commands don’t have the rich streams that PowerShell cmdlets have.
Although a non-zero exit code does NOT always indicate an error, the convention for native commands is that a non-zero exit code typically indicates an error.

A new feature $PSNativeCommandUseErrorActionPreference
allows you to have PowerShell treat a non-zero exit code as an error.
This means that you can set $ErrorActionPreference
to Stop and have PowerShell stop execution whether a cmdlet had an error or a native command had a non-zero exit code.

This simplifies scripts that previously would have to check $LASTEXITCODE
after execution of a native command or wrap it in a helper function.

What’s next?

PowerShell 7.4 will be our next LTS release and expected to be built on .NET 8 for next year.
We’ll have a separate blog post early next year to discuss the investments of the PowerShell/OpenSSH team for 2023.
We appreciate all the efforts of the community, both individuals and working group members,
and look forward to your continued feedback and contributions!

The post PowerShell 7.3 General Availability appeared first on PowerShell Team.

Overview

We are happy to announce the release of PSScriptAnalyzer 1.21. This minor version update includes:

• Three new rules
• Enhances one rule
• Pipeline support to Invoke-Formatter
• Four bug fixes
• Improved message details in PSUseCorrectCasing
• Lots of documentation updates
• Updated system requirements

A big portion of changes are in less visible areas such as the maintenance of dependencies and CI.

System requirements

Starting with this version the minimum requirements are changing as follows:

• For PowerShell ‘Core’ users ($PSVersionTable.PSEdition -eq 'Core'):

  The minimum required PowerShell version increases from 7.0.3 to 7.0.11. With PowerShell 7.0
  reached end of life this December, the next version of PSScriptAnalyzer will require 7.2.

  Use $PSVersionTable.PSVersion to see which version of PowerShell you are using. For more
  information about supported versions of PowerShell, see the
  PowerShell support lifecycle.

• For Windows PowerShell users (version 3 to 5.1 or ($PSVersionTable.PSEdition -ne 'Core'))

  The minimum required version of the .NET Framework runtime increased from 4.5.2 to 4.6.2.
  Versions 4.5.2., 4.6 and 4.6.1 have reached end of support this year. This change should not
  impact the majority of users on supported and patched OS versions.

  For more details about .NET support, see
  .NET Framework blog post.

For more information, see the full changelog.

New Rules

AvoidMultipleTypeAttributes

This rule is to call out the usage of multiple type attributes in a function that the parser accepts
as valid syntax but can later cause unexpected behavior or an error at runtime.

For example, the following function

function foo { [switch][string] $Param1 }

will throw the following error when the function is invoked:

Cannot convert the “” value of type “System.String” to type “System.Management.Automation.SwitchParameter”

Thanks to GitHub user hankyi95 for contributing this rule.

AvoidSemicolonsAsLineTerminators

The rule detects the usage of a trailing semicolon at the end of a line, which is not required in
most PowerShell scripts and can be omitted. This rule is not enabled by default and can be used by
Invoke-Formatter.

The latest Preview version of the PowerShell extension for Visual Studio Code already includes
PSScriptAnalyzer 1.21.0 and can control this formatting rule via a new
powershell.codeFormatting.avoidSemicolonsAsLineTerminators setting. This should soon be available
in the non-preview version of the extension as well.

Thanks to Aliaksei (GitHub user tempora-mutantur) for contributing this rule.

AvoidUsingBrokenHashAlgorithms

This rule inspects the Get-FileHash cmdlet for usage of either MD5 or SHA-1 as the value
to the -Algorithm parameter since those algorithms are no longer considered secure. Users
should consider replacing the value with SHA256, SHA384, SHA512, or other safer algorithms
where possible. It is understood there will be legacy or backwards compatibility cases where this
cannot be done. PSScriptAnalyzer has a suppression feature that can be used to document the
reason for it in your code.

Thanks to Michael Van Leeuwen (GitHub user MJVL) for contributing this rule.

Enhancements

Invoke-Formatter now accepts input via the pipeline, either just as a string or
[pscustomobject] with parameter values.

The AvoidUsingPlainTextForPassword rule is the first built-in rule to now return more than one
suggestion for correction. In addition to suggesting the usage of SecureString, it now offers
an alternative suggestion with PSCredential.

With version 2.40.0 of the az CLI, its entrypoint changed from a batch script to an az.ps1
script. Since this script just passed its received arguments as $args as-is to python, it is still
a CLI and not a script with parameters. But it causes now a AvoidUsingPositionalParameters
warning, which is a false positive. We therefore added a CommandAllowList configuration to it,
which has az in it by default.

Documentation changes

In order to keep documentation all consolidated in one location, we have moved the documentation in
the repo to the repo of docs.microsoft.com. Please see the documentation notice in the
repo in order to get more specific details.

Outlook

Expect more formatting rules and options in the next release and continue giving us feedback. We are
looking to increase our release frequency now that the Microsoft internal build has moved to a new
system, which is what caused some delay to this release. To reduce maintenance, we are looking to
drop support for PowerShell version 3 and 4 in future versions of PSScriptAnalyzer, which would also
align it with the PowerShell extension for Visual Studio Code where this change was successful. The
first step could be to increase the value of the PowerShellVersion property in the module manifest
but still ship the version specific binaries so that it would still work if one changed its value in
the manifest.

On behalf of the Script Analyzer team,

Christoph Bergmeister, Project Maintainer from the community, Avanade

Jim Truher, Senior Software Engineer, PowerShell Team, Microsoft

The post PSScriptAnalyzer (PSSA) 1.21.0 has been released appeared first on PowerShell Team.

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

This release includes a number of bug fixes as well as support for specifying the temporary path used during installation of PSResources.

How to Install PowerShellGet 3.0 Preview 17

Prerequisites

Please note that this preview release of PowerShellGet 3.0 does not support PowerShell 7.0, 7.1 or 7.2-preview1.

This is a temporary issue due to a dependency and should be resolved in future releases. This release does support Windows PowerShell 5.1, PowerShell 7.2 and 7.3-previews.

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

If you have PowershellGet v3 already you can run Update-PSResource PowerShellGet -Prerelease

What to expect in this update

This release includes a number of bug fixes as well as additional support for specifying a temporary path for installation of PSResources. For additional context on scenarios where this may be useful please refer to this issue.

Features of this release

• Add -TemporaryPath parameter to Install-PSResource, Save-PSResource, and Update-PSResource
• Add String and SecureString as credential types in PSCredentialInfo
• Expand acceptable paths for Publish-PSResource (Module root directory, module manifest file, script file)
• Add -Force parameter to Register-PSResourceRepository cmdlet, to override an existing repository
• Add a warning for when the script installation path is not in Path variable

Bug Fixes

• Change casing of -IncludeXML to -IncludeXml
• Update priority range for PSResourceRepository to 0-100
• Editorial pass on cmdlet reference
• Fix issue when PSScriptInfo has no empty lines
• Make ConfirmImpact low for Register-PSResourceRepository and Save-PSResource
• Fix -PassThru for Set-PSResourceRepository cmdlet to return all properties
• Rename -FilePath parameter to -Path for PSScriptFileInfo cmdlets
• Fix RequiredModules description and add Find example to docs
• Remove unneeded inheritance in InstallHelper.cs
• Make -Path a required parameter for Save-PSResource cmdlet
• Improve script validation for publishing and installing

Features to Expect in Coming Preview Releases

This module is not yet complete. The focus for our next preview release is removing the dependency on the nuget APIs. This will allow us to resolve dependency loading issues that effect which versions of PowerShell this module will be compatible with. This update will also allow us to improve performance of the module and resolve a number of outstanding bugs that are due to limitations in the nuget APIs. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

To track issues/features for the next release, please refer to this GitHub project.

Timeline/Road Map

Expect to see preview releases as new functionality is added and bug fixes are made. User feedback will help us determine when we can have a Release Candidate version of the module which will be supported to be used in production. Based on user feedback, if we believe the 3.0 release is complete, then we will publish a 3.0 version of the module as Generally Available. Since these milestones are driven by quality, rather than date, we can not offer an exact timeline at this point.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 17 appeared first on PowerShell Team.

We are excited to announce that the August update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.

This release adds a walkthrough experience for getting started with PowerShell in VS Code, more regression tests, a major LSP client library update, and includes a number of bug fixes!

Updates in the August Release

Note that these updates all shipped in our PowerShell Preview Extension for VS Code before shipping in our stable channel.

Some highlights of August releases:

• vscode-powershell #4151 Add integratedConsole.startInBackground to completely hide the terminal.
• vscode-powershell #4080 Create a walkthrough experience for PowerShell. (Thanks @S-Hakim!)
• #⃣ vscode-powershell #4141 Improve language client library close action message.
• PowerShellEditorServices #1892 Add symbols for Pester setup and teardown blocks. (Thanks @fflaten!)
• PowerShellEditorServices #1891 Fix whitespace in Pester symbol and add test. (Thanks @fflaten!)
• PowerShellEditorServices #1887 Fix symbol highlight when hovering function name. (Thanks @fflaten!)
• PowerShellEditorServices #1897 – Add artificial stack frame to represent contexts without one.
• PowerShellEditorServices #1894 – Fix stepping while watch expressions or interactive pipeline is running.
• vscode-powershell #4128 – Update vscode-languageclient and refactor (a lot of TLC).
• vscode-powershell #3266 – Fix debugger to start language client when necessary.
• vscode-powershell #4120 Remove extraneous ) from the do-while snippet. (Thanks @ncook-hxgn!)
• PowerShellEditorServices #1874 Add end-to-end integration test with Vim.
• ‍ vscode-powershell #4112 Fix (and test) regression with PSScriptAnalyzer default rules.
• PowerShellEditorServices #1872 Add regression tests for parse error DiagnosticMarkers. (Thanks @fflaten!)
• ‍ PowerShellEditorServices #1869 – Fix duplicate DiagnosticMarkers when reopening a file. (Thanks @fflaten!)
• vscode-powershell #4100 Remove popup when extension updates.
• PowerShellEditorServices #1867 – Add regression test for when prompt is undefined.
• vscode-powershell #4073 – Fix bug where error in prompt function crashed REPL.

For the full list of changes please refer to our changelog.

Getting Started Walkthrough

As a part of this release we have introduced a getting started experience for PowerShell in VS Code. This experience was designed through a series of customer surveys and interviews conducted by our summer intern. The walkthrough can be accessed on the Getting Started page in VS Code, or through the command pallette.

We look forward to getting more feedback on this walkthrough and learning how we can improve it.

LSP Client Library Update

This release also includes a major update to our LSP client library dependency, vscode-languageclient. The extension uses this library to start, connect, and communicate with the LSP server, PowerShell Editor Services.

By incorporating this update in vscode-powershell #4128 we were able to prevent a number of race conditions that could be encountered during startup, as the latest version of this library allows us to register our notification and request handlers before starting the server. The lifecycle management code was also given some much needed attention, and so startup and shut-down is now a more stable experience.

Please note that due to an upstream change, there is now a second notification when the server is stopped. We are working with the upstream team to de-duplicate this popup, and are also contemplating enabling a configurable auto-restart of the server.

Getting Support and Giving Feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

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.

Sydney Smith and Andy Jordan PowerShell Team

The post PowerShell Extension for Visual Studio Code August 2022 Update appeared first on PowerShell Team.

We are excited to announce that the second preview of a rewrite of Microsoft.PowerShell.Archive, the module that lets you create and extract archives, is now available on the PowerShell Gallery.

This release is the second preview release of a rewrite of the module and is not feature complete. Please note that this release is only compatible with PowerShell 7.3.0-preview5 and up. For more information on what is proposed in this rewrite, or to give feedback on the design please refer to the RFC.

Installing the module

Please note that this release will only work with PowerShell 7.3.0-preview5 and up. Find and install the latest preview version of PowerShell here.

To install the Microsoft.PowerShell.Archive 2.0 preview 2 using PowerShellGet 2.2.5 run the following command

Install-Module Microsoft.PowerShell.Archive -AllowPrerelease

To install the Microsoft.PowerShell.Archive 2.0 preview 2 using PowerShellGet 3.0 previews run the following command

Install-PSResource Microsoft.PowerShell.Archive -Prerelease

Features of the release

This release contains the rewrite of the Expand-Archive cmdlet.

This cmdlet contains two parameter sets

Expand-Archive [-Path] <string> [[-DestinationPath] <string>] [-WriteMode {Create | Update | Overwrite}] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Expand-Archive [-LiteralPath <string>] [-DestinationPath] <string>]  [-WriteMode {Create | Update | Overwrite}] [-PassThru] [-Filter <string[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

Some features to note of this release

• Added -WriteMode parameter to Expand-Archive
• Added support for zip64
• Fixed a bug where the entry names of files in a directory would not be correct when compressing an archive

Features of the next release

The next release will focus on additional features of the module. To track the progress of this release, look at this project in our GitHub repository.

Giving Feedback and Getting support

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

If you encounter any issues with the module or have feature requests, the best place to get support is through our GitHub repository.

Sydney

PowerShell Team

The post Archive Module 2.0 Preview 2 appeared first on PowerShell Team.

We are pleased to announce the release of Get-WhatsNew, a cmdlet that delivers feature
information about new versions of PowerShell to your local terminal experience.

Stay informed with Get-WhatsNew

Between General Availability (GA), Long-Term Servicing (LTS), and Previews release, PowerShell ships
updates several times a year. At this pace, PowerShell users may become unaware of new features and
changes that improve automation, performance and security. Today, this information is provided through
release notes and the PowerShell
GitHub repository. Get-WhatsNew enables you to:

• Learn about new features that enable new solutions
• Get version-specific information to make upgrade decisions
• View the information in disconnected scenarios (data ships with module)
• View the information in Windows PowerShell 5.1 and higher
• Get information for a single random feature for a message-of-the-day (MOTD) experience
• Quickly open the release notes on the web version using the Online option

Installing WhatsNew

The Get-WhatsNew cmdlet ships in the
Microsoft.PowerShell.WhatsNew
module, which can be installed from the PowerShell Gallery.

Requirements:

• Microsoft.PowerShell.WhatsNew is a cross platform module that requires Windows PowerShell 5.1
  or higher

To install Microsoft.PowerShell.WhatsNew:

Install-Module -Name Microsoft.PowerShell.WhatsNew

To install Microsoft.PowerShell.WhatsNew using the new
PowerShellGet.v3

Install-PSResource -Name Microsoft.PowerShell.WhatsNew

Using Get-WhatsNew

Get-WhatsNew displays PowerShell features by version. The cmdlet includes
complete help with several examples. Here are some highlights to get started:

To get the complete help information for Get-WhatsNew

Get-Help Get-WhatsNew -Full

To display the release notes for the version of PowerShell in which the cmdlet is running.

Get-WhatsNew

To display the release notes for PowerShell 7.2 regardless of which version the cmdlet is running.

Get-WhatsNew -Version 7.2

To display one randomly selected section of the release notes per version of PowerShell selected.
Add this to your profile to receive a Message-Of-The-Day (motd).

Get-WhatsNew -Daily -Version 6.0, 7.0, 7.1, 7.2

Future plans

We value your ideas and feedback and hope you will give WhatsNew a try. Stop by our
GitHub repository and let us know of any issues you find
or features you would like added.

The post Announcing the release of Get-WhatsNew appeared first on PowerShell Team.

We are excited to announce that the July update to the PowerShell Extension for Visual Studio Code

is now available on the extension marketplace.

This release renames the “PowerShell Integrated Console” to the “PowerShell Extension Terminal” to align with VS Code’s verbiage, adds many regression tests, and includes a number of bug fixes!

Updates in the July release

Note that these updates all shipped in our PowerShell Preview Extension
for VS Code before shipping in our stable channel.

Some highlights of July release:

• vscode-powershell #4093 – Use globalStorageUri for log and session files.
  • vscode-powershell #4053 – Rename “Integrated Console” to “Extension Terminal”.
  • PowerShellEditorServices #1849 – Add Directory.Exists() check to SetInitialWorkingDirectoryAsync().

For the full list of changes please refer to our changelog.

Improvements to our tests

We are currently building out regression tests for the extension to cover everything we broke and subsequently fixed during the major rewrite earlier this year. We have a strong focus on quality,
and want to ensure we continue to deliver a production-ready, high-quality extension to you, our users.
We have made a large investment in improving the extension so we want to be able to
confidently continue to iterate on this project without inadvertently impacting the performance, stability, or feature set.

We’ve begun this work already, and are tracking in our GitHub repository.

Some highlights of this work so far include:

• PowerShellEditorServices #1846 – Add end-to-end Pester unit test.
• PowerShellEditorServices #1857 – Add regression test for $PSDebugContext in prompt function.
• PowerShellEditorServices #1858 – Add regression test for debugging script with dot-source operator.
• PowerShellEditorServices #1861 – Add DebuggerBreaksInUntitledScript unit test.
• PowerShellEditorServices #1859 – Update and extend CI matrix.
• PowerShellEditorServices #1793 – Improve CI stability.

Getting support and giving feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

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.

Sydney
PowerShell Team

The post PowerShell Extension for Visual Studio Code July 2022 Update appeared first on PowerShell Team.

We are excited to announce that an update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery!

This release includes ScriptFileInfo cmdlets, Update-ModuleManifest support, and an AuthenticodeCheck for Install.

How to Install PowerShellGet 3.0 Preview 16

Prerequisites

Please note that this preview release of PowerShellGet 3.0 does not support PowerShell 7.0, 7.1 or 7.2-preview1.

This is a temporary issue due to a dependency and should be resolved in future releases. This release does support Windows PowerShell 5.1, PowerShell 7.2 and 7.3-previews.

Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed. To check the version you currently have installed run the command Get-InstalledModule PowerShellGet, PackageManagement

The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7. To install the latest versions of these modules run the following: Install-Module PowerShellGet -Force -AllowClobber

Installing the Preview

To install this preview release side-by-side with your existing PowerShellGet version, open any PowerShell console and run: Install-Module PowerShellGet -Force -AllowPrerelease

What to expect in this update

This update adds a number of cmdlets related to package metadata as well as a new -AuthenticodeCheck parameter for Install-PSResource, Save-PSResource, Update-PSResource.

Features of this release

• New-ScriptFileInfo
• Update-ScriptFileInfo
• Test-ScriptFileInfo
• Update-ModuleManifest
• Implementation of Authenticode validation via -AuthenticodeCheck for Install-PSResource

Bug Fixes

• Bug fix for installing modules with manifests that contain dynamic script blocks

Using -AuthenticodeCheck

In PowerShellGetv2 we performed what was called a PublisherCheck, for the sake of clarity in PowerShellGet 3.0 we have renamed this check to be specific to the check being made. The parameter is now opt-in and is called -AuthenticodeCheck. This check validates signed files and catalog files on Windows.

Features to Expect in Coming Preview Releases

This module is not yet complete. The focus for our next preview release is improving the performance of find/install. For the full list of issues for our next preview release please refer to our GitHub project.

How to Track the Development of this Module

GitHub is the best place to track the bugs/feature requests related to this module. We have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label Resolved-3.0 to label issues that we plan to release at some point before we release the module as GA (generally available).

To track issues/features for the next release, please refer to this GitHub project.

Timeline/Road Map

Expect to see preview releases as new functionality is added and bug fixes are made. User feedback will help us determine when we can have a Release Candidate version of the module which will be supported to be used in production. Based on user feedback, if we believe the 3.0 release is complete, then we will publish a 3.0 version of the module as Generally Available. Since these milestones are driven by quality, rather than date, we cannot offer an exact timeline at this point.

How to Give feedback and Get Support

We cannot overstate how critical user feedback is at this stage in the development of the module. Feedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.

In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our GitHub repository.

Sydney Smith

PowerShell Team

The post PowerShellGet 3.0 Preview 16 appeared first on PowerShell Team.

We are excited to announce that the first preview of a rewrite of Microsoft.PowerShell.Archive, the module that lets you create and extract archives, is now available on the PowerShell Gallery.

This release is the first preview release of a rewrite of the module and is not feature complete. Please note that this release only contains the Compress-Archive cmdlet and is only compatible with PowerShell 7.3.0-preview5 and up. For more information on what is proposed in this rewrite, or to give feedback on the design please refer to the RFC.

Goals of the 2.0 release

The goal for the Archive module is to build a high-performing and maintainable module that offers high utility and works cross-platform (especially with regard to file paths).

Currently, the archive module has a number of limitations. The module supports the zip32 format only. .NET 7 is planned to support the tar archive format, so there is an opportunity to support an additional archive format by taking advantage of these new APIs. Meanwhile, this opportunity can be leveraged not only to add tar support, but to rewrite the entire module in C# and address existing usability issues.

The module has limited performance compared to other archive software. Although performance is dictated by the .NET APIs, a rewrite of the module in C# can reduce the overhead from script modules and address performance issues to an extent.

The module has limited cross-platform support because archive entries are written in an OS-specific way due to different characters being used as directory separators in different OSs. This makes it difficult for Unix-based OS users to use archives compressed on a Windows computer or vice versa. The rewrite of the module can solve this problem by normalizing all paths to use Unix directory separators (the ‘/’ character) across all platforms.

There are a number of issues in regard to using wildcard characters in paths. For example, in some cases, wildcard characters are not interpreted literally, which makes it difficult to use paths containing wildcard characters to specify the location of the archive.

In some circumstances, error reporting can be improved and more descriptive. Compatibility with other archive software can also be improved as there are cases where an archive program may not recognize an archive produced by this module as valid. Interactions with other parts of PowerShell, such as the job system, advanced functions, and common parameters can be further improved, so that users can have a seamless experience when using the module.

Additionally, .NET has supported creating large archives and compressing large files, but the archive module has lacked support for this. It makes sense to support archive formats that are supported by .NET, such as zip64 and tar, and to provide options that .NET also provides. The next version of the archive module, Microsoft.PowerShell.Archive v2.0.0, plans on resolving these limitations and usability issues.

Installing the module

Please note that this release will only work with PowerShell 7.3.0-preview5 and up. Find and install the latest preview version of PowerShell here.

To install the Microsoft.PowerShell.Archive 2.0 preview 1 run the following command

Install-Module Microsoft.PowerShell.Archive -AllowPrerelease

Features of the release

This release is not feature complete and only contains the rewrite of the Compress-Archive cmdlet.

This cmdlet contains two parameter sets

    Compress-Archive [-Path] <string[]> [-DestinationPath] <string> [-WriteMode {Create | Update | Overwrite}] [-PassThru] [-CompressionLevel {Optimal | Fastest |
    NoCompression | SmallestSize}] [-Format {zip}] [-WhatIf] [-Confirm] [<CommonParameters>]

    Compress-Archive [-LiteralPath] <string[]> [-DestinationPath] <string> [-WriteMode {Create | Update | Overwrite}] [-PassThru] [-CompressionLevel {Optimal |
    Fastest | NoCompression | SmallestSize}] [-Format {zip}] [-WhatIf] [-Confirm] [<CommonParameters>]

Some features to note of this release

• Support for zip32 & zip64
• Preserves relative path structure (when relative paths are specified)
• Improved performance from previous versions of the cmdlet
• New -WriteMode support in case of destination path collisions

Features of the next release

The next release will focus in the Expand-Archive cmdlet. To track the progress of this release, look at this project in our GitHub repository.

Giving Feedback and Getting support

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

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.

Abdullah Yousuf

Sydney Smith

The post Archive Module 2.0 Preview 1 appeared first on PowerShell Team.

We are excited to announce that an update to the PowerShell Extension for Visual Studio Code is now available on the extension marketplace.

This release fixes a number of issues related to IntelliSense and enables updates to PowerShell Editor Services (the engine of the VS Code extension) for other clients, such as Emacs and Vim with LSP plug-ins.

Updates from the June releases

Some highlights of June releases:

• Fix how we check extension mode. vscode-powershell #3992

• Add warning about IntelliSense to PowerShell Integrated Console terminate dialog. (Thanks @JustinGrote!) vscode-powershell #3976

• Add regression test for no defined profiles. PowerShellEditorServices #1821

• Add Emacs regression tests for PowerShellEditorServices. PowerShellEditorServices #1820

• Set IsDebuggingRemoteRunspace sooner for attach. PowerShellEditorServices #1815

• Fix error when piping IFilePosition to ConvertTo-ScriptExtent. PowerShellEditorServices #1814

• Additional IntelliSense fixes and ToolTip overhaul. PowerShellEditorServices #1809

• Fix startup bug when zero profiles are present. PowerShellEditorServices #1807

• Fix execution of debug prompt commands. vscode-powershell #3980

• Re-enable stdio clients by fixing initialization sequence. PowerShellEditorServices #1695

• Fix a lot of IntelliSense issues. PowerShellEditorServices #1799

• Increase stack size for PowerShell 5. (Thanks @nohwnd!) vscode-powershell #3962

For the full list of changes please refer to our changelog.

IntelliSense improvements

In this release we have made a number of improvements to IntelliSense (the general term for various code editing features including: code completion, parameter info, tool-tip hovers, etc.).

Mark completion request handler as serial

Previously, if you typed Get- very quickly, you’d get no results at all. This stops completion from being cancelled whenever a DidChangeTextDocument notification is sent. This also lets completion cancel some other expensive requests like code lenses, which means everything is both speedier and less flaky.

Fix tasks never completing if cancelled quickly

We were exiting SynchronousTask.ExecuteSynchronously early if the cancellation was already requested. This was not setting our state correctly, causing the caller to just fall off without warning. This made some things like finally and using disposals never happen, which led to a lot of erratic behavior!

Make alias discovery possible on idle

The use of Runspace.SessionStateProxy while the pipeline thread is busy (even if you are on the pipeline thread) results in an exception. By fixing this we can also cancel GetAliasesAsync (a slow operation) when needed, and do it while idling instead of startup.

Add “space” character to completion trigger characters

Adding the “space” character to completion triggers lets us automatically give completion results for parameter values. This also required building in some support for marking completion results as “incomplete”. This means that the client will not cache results when standard identifier characters are typed.

Mainly, this solves the scenario where you type space, get file completion results, and then type -. You expect to then get parameter names, but without marking “incomplete”, it will instead filter the file results.

Also fixed a scenario where you type $script: and on typing the : it would not update to available script scope variables.

Make completion requests cancellable

Now any completion results from custom argument completers can be cancelled if they take too long and the user keeps typing. In non-remote runspaces, we can also use it as a completion source that we can cancel by way of issuing a pipeline stop request.

What’s next for the project?

We are currently building out regression tests for the extension to cover everything we broke and subsequently fixed during the major rewrite earlier this year. We have a strong focus on quality, and want to ensure we continue to deliver a production-ready, high-quality extension to you, our users. We have made a large investment in improving the extension so we want to be able to confidently continue to iterate on this project without inadvertently impacting the performance, stability, or feature set. We’ve begun this work already, and are tracking in our GitHub repository.

Getting support and giving feedback

While we hope the new implementation provides a much better user experience, there are bound to be issues. Please let us know if you run into anything.

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.

Sydney

PowerShell Team

The post PowerShell Extension for Visual Studio Code June 2022 Update appeared first on PowerShell Team.