PowerShellGet 3.0 Preview 14

Sydney Smith

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 PowerShellGet\Install-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