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 more parameters, additional pipeline support, more wildcard support and a number of other features detailed below.

How to Install PowerShellGet 3.0 Preview 12

Prerequisites

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 wildcard and pipeline support for some cmdlets, adds a number of parameters and parameter sets, and includes many bug fixes. Some of the key features and breaking changes are listed below, for the full list of changes please refer to the Changelog.

Features

• Wildcard support for Find-PSResource -Name
• Support searching for and returning packages found across multiple repositories when using wildcard with Repository parameter (i.e Find-PSResource “PackageExistingInMultipleRepos” -Repository “*” will perform an exhaustive search).
• Parameter set for Find-PSResource -Tag
• Parameter set for Find-PSResource -Type
• Parameter set for Find-PSResource -CommandName
• Parameter set for Find-PSResource -DSCResourceName
• -DestinationPath parameter for Publish-PSResource
• -NoClobber functionality to Install-PSResource
• Pipeline support for Install-PSResource, Uninstall-PSResource, Save-PSResource, Find-PSResource, Get-PSResource, Publish-PSResource, Get-PSResourceRepository, Set-PSResourceRepository, Register-PSResourceRepository, Unregister-PSResourceRepository
• Consistent pre-release version support for cmdlets, including Uninstall-PSResource and Get-PSResource. For example, running Get-PSResource “MyPackage” -Version “2.0.0-beta” would only return MyPackage with version “2.0.0” and prerelease “beta”, NOT MyPackage with version “2.0.0.0” (i.e a stable version).
• -AsNupkg and -IncludeXML parameters for Save-PSResource
• -PassThru parameter for Install-PSResource, Save-PSResource,Update-PSResource and Unregister-PSResourceRepository
• -SkipDependencyCheck parameter for Install-PSResource, Save-PSResource and Update-PSResource cmdlets.
• Progress Bar for Install-PSResource, Update-PSResource and Save-PSResource
• -Quiet parameter for Install-PSResource, Save-PSResource and Update-PSResource (This suppresses the progress bar display when passed in)
• -AsNupkg and -IncludeXML parameters for Save-PSResource
• Improved error handling
• Restore package if installation attempt fails when reinstalling a package.

Breaking Changes

This release reverts the cmdlet name from Get-InstalledPSResource to Get-PSResource.

This release also removes the DSCResource from PowerShellGet, with the intention to continue shipping the DSCResource on the PowerShell Gallery separately from the PowerShellGet module. If the DSCResource is critical for your workload we recommend staying on preview 11 until the resource is available on the Gallery. Currently the DSCResource can also be found in its own GitHub repository. If you are impacted by this change please open an issue in our GitHub repository to ensure your scenario is covered as we move towards GA for this major update.

Features to Expect in Coming Preview Releases

This module is not yet feature complete.
Below is a list of features that we are still in the process of implementing which you can expect to see in future preview releases.

• We will introduce a New-RequiredResourceFile cmdlet which will create a template file. If the switch -AsPSD1 is used it will create a psd1 file, otherwise it will default to JSON.
• New-ScriptFileInfo cmdlet
• Test-ScriptFileInfo cmdlet
• Update-ScriptFileInfo cmdlet
• Update-ModuleManifest cmdlet
• Dependency management. In future releases, Install-PSResource will accept a path to a psd1 or JSON file (using -RequiredResourceFile), or a hash table or JSON (using -RequiredResource) where the key is the module name and the value is either the required version specified using Nuget version range syntax or a hash table where repository is set to the URL of the repository and version contains the Nuget version range syntax.

Install-PSResource -RequiredResource @{
  Configuration = "[1.3.1,2.0]"

  Pester        = @{
    version = "[4.4.2,4.7.0]"
    repository = "https://www.powershellgallery.com"
    credential = $cred
    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:

{
  "Configuration": "[1.3.1,2.0]",

  "Pester": {
    "version": "[4.4.2,4.7.0]",
    "credential": null,
    "repository": "https://www.powershellgallery.com",
    "allowPrerelease": true
  }
}

• Save-PSResource -Type Library will download nupkgs that have a lib folder in order to make it easier to use arbitrary libraries with PowerShell scripts. The dependent native library in runtimes matching the current system runtime will be copied to the root of the destination specified. An -IncludeAllRuntimes can be used to explicitly retain the runtimes directory hierarchy within the nupkg to the root of the destination.
• Native credential management/credential persistence for registered PSRepositories
• For cmdlets with a –URL parameter, the parameter will be renamed to -Uri.

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.

Improvements we are Considering post-GA

One important goal of PowerShellGet 3.0 is to improve the supportability of the module. As a result, once this work is complete we will iterate more quickly, and tackle other top customer issues. This list represents issues we are considering tackling, but have not committed to yet.

To track the full list of issues we are considering we are using the vNext milestone 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.

Timeline/Roadmap

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, Amber Erickson, Anam Navied, Paul Higinbotham, Steven Bucher PowerShell Team

The post PowerShellGet 3.0 Preview 12 Release appeared first on PowerShell Team.