PowerShellGet 3.0 Preview 14

This post was originally published on this site

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 support for PSResourceRepository credential persistence, as well as support for RequiredResourceFiles for Install.

How to Install PowerShellGet 3.0 Preview 14


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

The key features and bug fixes are listed below, for the full list of changes please refer to the Changelog.

Features of this release

  • -Scope parameter for Get-PSResource and Uninstall-PSResource
  •  -CredentialInfo parameter for Register-PSResourceRepository
  • Clt+C support for Find-PSResource
  • -RequiredResource parameter for Install-PSResource
  • Publish-PSResource Script publishing support
  • -Prerelease support for Uninstall-PSResource
  • Install-PSResource -RequiredResourceFile parameter for psd1 and json
  • -RequiredResource parameter Install-PSResource

Bug Fixes

  • RequiredModules support for publishing
  • Register-PSResourceRepository -Repositories parameter renamed to -Repository
  • Rename PSResourceInfo’s PrereleaseLabel property to match Prerelease column displayed
  • Parameter consistency: change url to uri

Using Credential Persistence

This community contributed feature allows you to provide information about where a credential is stored when registering the PSResourceRepository using a -CredentialInfo parameter. This parameter takes a PSCredentialInfo object which takes a vault name and secret name. The secret will then be pulled to authenticate to the Repository on Find and Install calls. This feature takes advantage of SecretManagement, for more information on SecretManagement refer the documentation.


  • Microsoft.PowerShell.SecretManagement
  • Any vault extension registered (for this example I will use Microsoft.PowerShell.SecretStore)
  • A repository to connect to (for this example I will use Artifactory)

Getting started

For this example I am going to be using SecretStore to store my credentials for an Artifactory repository. This can be repeated with any SecretManagement extension vault, and with any repository. First, I need to make sure I have a SecretManagement vault set up, with my credential stored. Currently this feature only supports the PSCredential secret type, however, we have an issue to track support for other types.

PS C:Users > Get-SecretInfo
Name          Type         VaultName
----          ----         ---------
jFrogCred     PSCredential SecretStore

Then I can create a PSCredentialInfo object to pass into my PSResourceRepository registration, to create this I pass in the name of the vault and the name of the secret.

$credentialInfo = New-Object Microsoft.PowerShell.PowerShellGet.UtilClasses.PSCredentialInfo ("SecretStore", "jfrogCred")

Now I am ready to register the PSResourceRepository, I will pass in a friendly name, a URI for the repository, and the CredentialInfo. I also use the -Trusted switch because I will be controlling what gets published to the repository.

Register-PSResourceRepository -Name artifactory `
-URI " https://<name>.jfrog.io/artifactory/api/nuget/v3/<Repository-Name>
-Trusted `
-CredentialInfo $credentialInfo 

Now I can run Get-PSResourceRepository to see my registered repositories

PS C:Users > Get-PSResourceRepository

Name        Uri                                                                                     Trusted Priority
----        ---                                                                                     ------- --------
artifactory https://<name>.jfrog.io/artifactory/api/nuget/v3/<Repository-Name>                      True    50      
PSGallery   https://www.powershellgallery.com/api/v2                                                False   50  

If the repository is empty you are going to want to begin by publishing to it. I have saved my API key for publishing to the repository in my SecretStore.

Publish-PSResource -Path .Get-Hello -Repository artifactory -ApiKey (Get-Secret jfrogPublish)

Now I can find and install PSResources from my repository without needing to provide a credential at each call.

PS C:Users> Find-PSResource -Name Get-Hello -Repository artifactory

Name      Version Prerelease Repository  Description
----      ------- ---------- ----------  -----------
Get-Hello            artifactory test module

PS C:Users> Install-PSResource Get-Hello

Using Required Resources

Install-PSResource can accept a path to a psd1 or json file (using -RequiredResourceFile), or a hashtable or json (using -RequiredResource).

Getting Started

The -RequiredResource parameter can take either a hashtable or a json format string. The following example shows how to format these inputs.

Install-PSResource -RequiredResource @{
  'Configuration' = @{
    version = '[1.3.1,2.0]'
    repository = 'PSGallery'                        
  'Pester'        = @{
    version = '[4.4.2,4.7.0]'
    repository = 'PSGallery'
    allowPrerelease = $true

In this case the modules named “Configuration”, and “Pester” will be installed. The json format will be the same as if this hashtable is passed to ConvertTo-Json:

  'Pester': {
    'allowPrerelease': true,
    'version': '[4.4.2,4.7.0]',
    'repository': 'PSGallery'
  'Configuration': {
    'version': '[1.3.1,2.0]',
    'repository': 'PSGallery'

 Declared dependencies are searched and installed using the same trust algorithm as for Install-PSResource.

The -RequiredResourceFile parameter can accept either a psd1 or a json file. The psd1 should use the same format as the hashtable above, the json file should use the same format as the json sting above.

Features to Expect in Coming Preview Releases

This module is not yet feature complete. Below is a list of features which you can expect to see in the next preview release.

  • New-ScriptFileInfo cmdlet
  • Test-ScriptFileInfo cmdlet
  • Update-ScriptFileInfo cmdlet
  • Update-ModuleManifest cmdlet
  • -AuthenticodeCheck parameter switch for Save, Install, Update

Using the CompatPowerShellGet module

CompatPowerShellGet is a compatibility module that allows use of PowerShellGet 2.x (and below) cmdlet syntax with PowerShellGet 3.0 (and above) functionality by making a best effort mapping between the cmdlet interfaces of both versions of the module. New PowerShell scripts that only leverage PowerShellGet v3 cmdlets do not need to use this compatibility module. For example, if a user has the CompatPowerShellGet module installed and runs the command:

Install-Module PowerShellGet -MinimumVersion 1 -MaximumVersion 2 -AllowPrerelease

the CompatPowerShellGet module will get autoloaded into the PowerShell Session and will map the command to PowerShellGet 3.0 syntax:

Install-PSResource PowerShellGet -Version "[1,2]" -Prerelease" 

The command will then be executed by the PowerShellGet 3.0 implementation. The user will also get a warning to update their script to the new cmdlet interface:

WARNING: The cmdlet 'Install-Module' is deprecated, please use 'Install-PSResource.

This module is designed so that users will not need to immediately update their scripts in order to update to the latest version of PowerShell or to begin taking advantage of the performance improvements already available in PowerShellGet 3.0. We still do recommend that authors begin making the minimal changes required to update their scripts to the new cmdlet interface.

This compatibility module is designed so that it takes precedence over legacy versions of PowerShellGet. If you have this compatibility module installed and would not like it to be used, you can remove it from the PowerShell session using the Remove-Module command.

Please note that this flow is only possible if the user has both the CompatPowerShellGet module installed and the PowerShellGet 3.0 preview module installed. Once PowerShellGet 3.0 is generally available it will be a dependency of CompatPowerShellGet.

Please also note that this compatibility module will not be called if you use fully qualified cmdlets. For example, if you use PowerShellGetInstall-Module this will call a legacy version of PowerShellGet. If this is a common scenario for you, and will be a barrier to migrating to PowerShellGet 3.0 we would appreciate that feedback in our GitHub repository.

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.

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 14 appeared first on PowerShell Team.

Major update to the PowerShell Extension for Visual Studio Code

This post was originally published on this site

An updated version of our PowerShell extension is now available on the Visual Studio Code marketplace.

This update represents a complete overhaul of the core PowerShell engine of PowerShell Editor Services, intending to create a more reliable and stable user experience. This release represents nearly two years’ work, tracked in PSES #1295 and implemented in PSES #1459. It is our response to many issues opened by users over the last several years.

Thank you to all of the community members who opened issues which helped motivate this major update.

These major updates have also been tested over the last 6 months, in 13 releases of our PowerShell Preview extension for Visual Studio Code. A huge thank you to all of the community members who have tested these changes to the extension and have worked with us to polish the extension before releasing it through our stable channel.

For information on getting started with the PowerShell extension for Visual Studio Code refer to our documentation.

Highlights of the release

  • Rewrite of PowerShell pipeline execution with cancellable and ordered tasks
  • Loads of debugger reliability improvements
  • ReadKey fix (including better pasting on macOS and Linux, and a whole bunch of other bugs!)
  • Revamped PSHost implementation that reuses PowerShell’s built-in functionality wherever possible
  • Improved testing (in VS Code repo and PSES repo)
  • Improved completion logic (and more icons!)
  • Modernized built-in snippets
  • Improved user interface with built-in Codicons
  • Improved settings editor experience
  • Support debugging without a workspace
  • Support to debug other PowerShell processes and runspaces
  • DictionaryEntry displayed as key/value pairs in debugger
  • Removed PackageManagement module update prompt
  • Enabled resolution of an alias to its function definition
  • Fix formatting handlers and PSScriptAnalyzer loading
  • Performance improvements with better cancellation logic

For a complete list of changes please refer to our changelog.

More about the update

We began our work for this update with the following goals for the release to our stable extension

  • More reliable/stable experience overall
  • All tests are enabled and improved in both client (extension) and server (PSES) repositories
  • Feature parity with previous extension experience (or intentional depreciation of features)
  • No new moderate to high impact bugs

To accomplish these goals we focused on the threading model for the extension.

Previously the Integrated Console, the shell that is provided by the PowerShell extension, was run by setting threadpool tasks on a shared main runspace, and where LSP, Language Server Protocol, servicing was done with PowerShell idle events. This lead to overhead, threading issues and a complex implementation intended to work around the asymmetry between PowerShell as a synchronous, single-threaded runtime and a language server as an asynchronous, multi-threaded service.

Now, PowerShell Editor Services maintains its own dedicated pipeline thread, which is able to service requests similar to JavaScript’s event loop, meaning we can run everything synchronously on the correct thread. This prevents an entire class of race conditions, leading to more reliable and bug-free code. We also get more efficiency because we can directly call PowerShell APIs and code written in C# from this thread, without the overhead of a PowerShell pipeline.

This change has overhauled how we service LSP requests, how the Integrated Console works, how PSReadLine is integrated, how debugging is implemented, how remoting is handled, and a long tail of other features in PowerShell Editor Services.

Also, in making it, while 6,000 lines of code were added, we removed 12,000, for a more maintainable, more efficient and easier to understand extension backend.

What’s next for the extension

Beyond this release our intention is to remain focused on incremental improvements to the stability, reliability, and consistency of the extension. These next work items are enumerated in our GitHub Projects.

In particular we plan to focus on known issues with debugging and start-up.

Feedback and 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.


Sydney Smith

PowerShell Team

The post Major update to the PowerShell Extension for Visual Studio Code appeared first on PowerShell Team.