{"id":19114,"date":"2021-08-09T14:15:47","date_gmt":"2021-08-09T22:15:47","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=19114"},"modified":"2022-04-21T12:02:35","modified_gmt":"2022-04-21T20:02:35","slug":"powershellget-3-0-preview-11-release","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershellget-3-0-preview-11-release\/","title":{"rendered":"PowerShellGet 3.0 Preview 11 Release"},"content":{"rendered":"<p>We are excited to announce that an important update to our <a href=\"https:\/\/www.powershellgallery.com\/packages\/PowerShellGet\/\">preview of PowerShellGet 3.0<\/a> is now available on the PowerShell Gallery!<\/p>\n<p>This preview release marks the completion of a complete refactor of this module and is a major step towards being feature complete for PowerShellGet 3.0.<\/p>\n<p>PowerShellGet 3.0 is a complete re-write of PowerShellGet with the following goals:<\/p>\n<ul>\n<li><em>Create a more intuitive package manager<\/em>: Make PowerShellGet more intuitive and easier to use by removing unnecessary prompts when possible.<\/li>\n<li><em>Address top customer issues<\/em>: Many of the top customer issues in previous versions of the module have been challenging to resolve because of architecture decisions made early on in the development of PowerShellGet. Below we enumerate many of these issues we hope to resolve. To view a full enumeration of these issues see <a href=\"https:\/\/github.com\/PowerShell\/PowerShellGet\/milestone\/3\">this GitHub milestone<\/a>.<\/li>\n<li><em>Allow for a smooth transition to v3<\/em>: Transitioning from lower versions of PowerShellGet to 3.0 and above should be as painless as possible. With the help of our compatibility module, <a href=\"https:\/\/www.powershellgallery.com\/packages\/CompatPowerShellGet\">CompatPowerShellGet<\/a>, explained in more detail below, our goal is to enable users and scripts built on PowerShellGet 2.0 to move seamlessly to 3.0.<\/li>\n<li><em>Improve maintainability of the codebase<\/em>: This goal is addressed by removing the provider model that PowerShellGet was originally built on.<\/li>\n<\/ul>\n<p>This means that PowerShellGet 3.0 does not take a dependency on PackageManagement, NuGet or any other package provider, simplifying the codebase.<\/p>\n<p>Using the lessons learned from previous versions of the module, along with a cleaner implementation and interface, we have improved efficiency and quality, allowing us to more quickly address bugs as they arise and iterate on our vNext issues.<\/p>\n<p>The purpose of this release to get critical user feedback to improve the module through subsequent preview releases before we finalize the design for a Release Candidate expected later this year.<\/p>\n<p>It&#8217;s been many months since our last release, but we believe that this preview is well worth the wait. We&#8217;ve spent the last 6+ months working on bringing PowerShellGet 3.0 from a prototype stage to something efficient, maintainable, fully tested, and backwards compatible.<\/p>\n<h2>How to Install PowerShellGet 3.0 Preview 11<\/h2>\n<h3>Prerequisites<\/h3>\n<p>Please ensure that you have the latest (non-prerelease) version of PowerShellGet and PackageManagement installed.\nTo check the version you currently have installed run the command:<\/p>\n<p><code>Get-InstalledModule PowerShellGet, PackageManagement<\/code><\/p>\n<p>The latest version of PowerShellGet is 2.2.5, and the latest version of PackageManagement is 1.4.7.\nTo install the latest versions of these modules run the following:<\/p>\n<p><code>Install-Module PowerShellGet -Force -AllowClobber<\/code><\/p>\n<h2>Installing the Preview<\/h2>\n<p>To install this preview release side-by-side with your existing PowerShellGet version,\nopen any PowerShell console and run:<\/p>\n<p><code>Install-Module PowerShellGet -Force -AllowPrerelease<\/code><\/p>\n<p>If you run the command <code>Get-Command -ModuleName PowerShellGet<\/code> you will get a good picture of the\nside-by-side cmdlet interfaces.<\/p>\n<pre><code class=\"language-console\">CommandType     Name                                               Version    Source\r\n-----------     ----                                               -------    ------\r\nCmdlet          Find-PSResource                                    3.0.0      PowerShellGet\r\nCmdlet          Get-PSResource                                     3.0.0      PowerShellGet\r\nCmdlet          Get-PSResourceRepository                           3.0.0      PowerShellGet\r\nCmdlet          Install-PSResource                                 3.0.0      PowerShellGet\r\nCmdlet          Publish-PSResource                                 3.0.0      PowerShellGet\r\nCmdlet          Register-PSResourceRepository                      3.0.0      PowerShellGet\r\nCmdlet          Save-PSResource                                    3.0.0      PowerShellGet\r\nCmdlet          Set-PSResourceRepository                           3.0.0      PowerShellGet\r\nCmdlet          Uninstall-PSResource                               3.0.0      PowerShellGet\r\nCmdlet          Unregister-PSResourceRepository                    3.0.0      PowerShellGet\r\nCmdlet          Update-PSResource                                  3.0.0      PowerShellGet<\/code><\/pre>\n<h2>Features<\/h2>\n<ul>\n<li>A complete refactor of cmdlets which abstract all PSResource types (Module, Script, DSCResource, RoleCapability, Command) to a single set of cmdlets which use the noun &#8220;PSResource&#8221;.\nMany of these cmdlets use a <code>-Type<\/code> parameter for the user to specify the PSResource type if they would like. For example:<code class=\"language-powershell\" style=\"font-size: 14.4px;\">Find-PSResource -Name PowerShellGet -Type Module -Prerelease<\/code><\/li>\n<\/ul>\n<ul>\n<li>For the cmdlets <code>Register-PSRepository<\/code> and <code>Set-PSRepository<\/code> a <code>-Priority<\/code> parameter allows setting the search order of repositories with a lower value indicating a higher priority. This addresses a common complaint with lower versions of PowerShellGet, which is that a resource found in multiple repositories would trigger a prompt that would require the user to specify which repository specifically the resource should come from.\nWith this new feature, if <code>-Priority<\/code><span style=\"font-size: 1rem;\"> is not specified, the default value is 50. The PSGallery, which is registered by default, has an editable value of 50.\n<\/span>If two PSRepositories have the same priority the &#8220;Trusted&#8221; one will be chosen, if they also have the same level of trust the first one alphabetically will be selected. Of course, a specific repository can always be specified.<\/li>\n<\/ul>\n<ul>\n<li style=\"list-style-type: none;\">\n<ul>\n<li>For <code>Find-PSResource<\/code> the <code>-Repository<\/code> parameter supports wildcard search.\nIf no repository is specified, the cmdlet will return the latest version found from the repository with the highest priority.<\/p>\n<pre><code class=\"language-console\">Find-PSResource Az.Sql -Repository *\r\n\r\nName   Version Repository      Description\r\n----   ------- ----------      -----------\r\nAz.Sql 2.5.0   PSGallery       Microsoft Azure PowerShell - SQL service cmdlets for Azure Resource...\r\nAz.Sql 2.5.0   PoshTestGallery Microsoft Azure PowerShell - SQL service cmdlets for Azure Resource...<\/code><\/pre>\n<pre><code class=\"language-console\">Find-PSResource Az.Sql\r\n\r\nName   Version Repository      Description\r\n----   ------- ----------      -----------\r\nAz.Sql 2.5.0   PSGallery       Microsoft Azure PowerShell - SQL service cmdlets for Azure Resource...<\/code><\/pre>\n<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>For <code>Find-PSResource<\/code> and <code>Install-PSResource<\/code> the <code>-Version<\/code> parameter will accept strings (with wildcard support) based on the <a href=\"https:\/\/docs.microsoft.com\/en-us\/nuget\/reference\/package-versioning#version-ranges-and-wildcards\">Nuget version range syntax<\/a>:\n<pre><code class=\"language-console\">Find-PSResource Microsoft.PowerShell.GraphicalTools -Version *\r\nName                                Version Repository Description\r\n----                                ------- ---------- -----------\r\nMicrosoft.PowerShell.GraphicalTools 0.2.0   PSGallery  Cross-platform GUI Tools for Pow\u2026\r\nMicrosoft.PowerShell.GraphicalTools 0.1.1   PSGallery  Cross-platform GUI Tools for Pow\u2026<\/code><\/pre>\n<pre><code class=\"language-console\">Find-PSResource Microsoft.PowerShell.GraphicalTools -Version \"(0.0,1.0)\"\r\n\r\nName                                Version Repository Description\r\n----                                ------- ---------- -----------\r\nMicrosoft.PowerShell.GraphicalTools 0.2.0   PSGallery  Cross-platform GUI Tools for Pow\u2026<\/code><\/pre>\n<pre><code class=\"language-console\">Find-PSResource Microsoft.PowerShell.GraphicalTools -Version \"0.1.1\"\r\n\r\nName                                Version Repository Description\r\n----                                ------- ---------- -----------\r\nMicrosoft.PowerShell.GraphicalTools 0.1.1   PSGallery  Cross-platform GUI Tools for Pow\u2026<\/code><\/pre>\n<\/li>\n<\/ul>\n<ul>\n<li><code>Install-PSResource<\/code> has a <code>-DestinationPath<\/code> parameter which allows the user to specify the target directory instead of one based on the <code>-Scope<\/code> parameter (default Scope is <code>CurrentUser<\/code>). Note that in this release &#8220;x86&#8221; paths, and Linux paths are not yet supported. Expect to see this support in future releases.<\/li>\n<li><code>Update-PSResource<\/code> has an <code>-UpdateTo<\/code> parameter with values <code>MinorVersion<\/code> (the default), <code>MajorVersion<\/code>, and <code>PatchVersion<\/code>\n<code>MinorVersion<\/code> allows updating to the latest minor version (e.g. 6.2.1 to 6.3.0).\n<code>MajorVersion<\/code> allows updating to the latest major version (e.g. 6.2.1 to 7.0.0).\n<code>PatchVersion<\/code> allows updating to the latest patch version (e.g. 6.2.1 to 6.2.4).<\/li>\n<li><code>Publish-PSResource<\/code> functionality<\/li>\n<li>There is support for NuGet v2 and v3 endpoints for PSRepositories.<\/li>\n<li>Error handling, warnings, <code>-Verbose<\/code>, and <code>-Debug<\/code> parameters<\/li>\n<\/ul>\n<p>For the full list of issues expected to be resolved in this release refer to <a href=\"https:\/\/github.com\/PowerShell\/PowerShellGet\/projects\/10\">this GitHub project<\/a>.\nIf any of the features on this list are not behaving how you would expect them to, or would prefer them to be sure to open an issue in our <a href=\"https:\/\/github.com\/PowerShell\/PowerShellGet\/issues\">GitHub repository<\/a>.<\/p>\n<h3>Features to Expect in Coming Preview Releases<\/h3>\n<p>This module is not yet feature complete.\nBelow is a list of features that we are still in the process of implementing which you can expect to see in future preview releases.<\/p>\n<ul>\n<li>We will introduce a <code>New-RequiredResourceFile<\/code> cmdlet which will create a template file.\nIf the switch <code>-AsPSD1<\/code> is used it will create a psd1 file, otherwise it will default to JSON.<\/li>\n<li><code>New-ScriptFileInfo<\/code> cmdlet<\/li>\n<li><code>Test-ScriptFileInfo<\/code> cmdlet<\/li>\n<li><code>Update-ScriptFileInfo<\/code> cmdlet<\/li>\n<li><code>Update-ModuleManifest<\/code> cmdlet<\/li>\n<li>Dependency management. In future releases, <code>Install-PSResource<\/code> will accept a path to a psd1 or JSON file (using <code>-RequiredResourceFile<\/code>), or a hash table or JSON (using <code>-RequiredResource<\/code>) 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 <code>repository<\/code> is set to the URL of the repository and\n<code>version<\/code> contains the <a href=\"https:\/\/docs.microsoft.com\/en-us\/nuget\/reference\/package-versioning#version-ranges-and-wildcards\">Nuget version range syntax<\/a>.<\/li>\n<\/ul>\n<pre><code class=\"language-powershell\">Install-PSResource -RequiredResource @{\r\n  Configuration = \"[1.3.1,2.0)\"\r\n  Pester        = @{\r\n    version = \"[4.4.2,4.7.0]\"\r\n    repository = \"https:\/\/www.powershellgallery.com\"\r\n    credential = $cred\r\n    allowPrerelease = $true\r\n  }\r\n}<\/code><\/pre>\n<p>In this case the modules named &#8220;Configuration&#8221;, and &#8220;Pester&#8221; will be installed.\nThe JSON format will be the same as if this hashtable is passed to <code>ConvertTo-Json<\/code>:<\/p>\n<pre><code class=\"language-json\">{\r\n  \"Configuration\": \"[1.3.1,2.0)\",\r\n  \"Pester\": {\r\n    \"version\": \"[4.4.2,4.7.0]\",\r\n    \"credential\": null,\r\n    \"repository\": \"https:\/\/www.powershellgallery.com\",\r\n    \"allowPrerelease\": true\r\n  }\r\n}<\/code><\/pre>\n<ul>\n<li><code>Save-PSResource -Type Library<\/code> will download nupkgs that have a <code>lib<\/code> folder\nin order to make it easier to use arbitrary libraries with PowerShell scripts.\nThe dependent native library in <code>runtimes<\/code> matching the current system runtime\nwill be copied to the root of the destination specified.\nAn <code>-IncludeAllRuntimes<\/code> can be used to explicitly retain the <code>runtimes<\/code> directory\nhierarchy within the nupkg to the root of the destination.<\/li>\n<li>Native credential management\/credential persistence for registered PSRepositories<\/li>\n<li><code>Publish-PSResource<\/code> will include a <code>-DestinationPath<\/code> parameter to publish a resource to a particular file path<\/li>\n<\/ul>\n<h3>Using the CompatPowerShellGet module<\/h3>\n<p>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.\nNew PowerShell scripts that only leverage PowerShellGet v3 cmdlets do not need to use this compatibility module.\nFor example, if a user has the CompatPowerShellGet module installed and runs the command:<\/p>\n<pre><code class=\"language-powershell\">Install-Module PowerShellGet -MinimumVersion 1 -MaximumVersion 2 -AllowPrerelease <\/code><\/pre>\n<p>the CompatPowerShellGet module will get autoloaded into the PowerShell Session and will map the command to PowerShellGet 3.0 syntax:<\/p>\n<pre><code class=\"language-powershell\">Install-PSResource PowerShellGet -Version \"[1,2]\" -Prerelease\" <\/code><\/pre>\n<p>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:<\/p>\n<pre><code class=\"language-powershell\">WARNING: The cmdlet 'Install-Module' is deprecated, please use 'Install-PSResource\u2019.<\/code><\/pre>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Please also note that this compatibility module will not be called if you use fully qualified cmdlets. For example, if you use <code>PowerShellGet\\Install-Module<\/code> 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 <a href=\"https:\/\/github.com\/powershell\/powershellget\">our GitHub repository<\/a>.<\/p>\n<h3>Improvements we are Considering post-GA<\/h3>\n<p>One important goal of PowerShellGet 3.0 is to improve the supportability of the module.\nAs 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.<\/p>\n<p>To track the full list of issues we are considering we are using the <a href=\"https:\/\/github.com\/PowerShell\/PowerShellGet\/milestone\/1\">vNext milestone<\/a> in our GitHub Repository.<\/p>\n<h2>How to Track the Development of this Module<\/h2>\n<p>GitHub is the best place to track the bugs\/feature requests related to this module.\nWe have used a combination of projects and labels on our GitHub repo to track issues for this upcoming release. We are using the label <code>Resolved-3.0<\/code> to label issues that we plan to release at some point in before we release the module as GA (generally available).\nTo track issues\/features to particular preview and GA releases we are using GitHub projects which are titled to reflect the release.<\/p>\n<h2>Timeline\/Roadmap<\/h2>\n<p>Expect to see preview releases more frequently as new functionality is added and bug fixes are made. Our goal is to keep a release cadence of roughly every 2 weeks. 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.\nBased 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.\nSince these milestones are quality, rather than date, driven we can not offer an exact timeline at this point, but hope to release the module later this year.<\/p>\n<h2>How to Give feedback and Get Support<\/h2>\n<p>We cannot overstate how critical user feedback is at this stage in the development of the module.\nFeedback from preview releases help inform design decisions without incurring a breaking change once generally available and used in production.<\/p>\n<p>In order to help us to make key decisions around the behavior of the module please give us feedback by opening issues in our <a href=\"https:\/\/github.com\/PowerShell\/PowerShellGet\">GitHub repository<\/a>.<\/p>\n<p>Sydney Smith, Amber Erickson, Anam Navied, Paul Higinbotham\nPowerShell Team<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We are excited to announce that an important update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery! This preview release marks the completion of a complete refactor of this module and is a major step towards being feature complete for PowerShellGet 3.0. PowerShellGet 3.0 is a complete re-write of PowerShellGet [&hellip;]<\/p>\n","protected":false},"author":67292,"featured_media":13641,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[274],"class_list":["post-19114","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-powershell","tag-powershellget"],"acf":[],"blog_post_summary":"<p>We are excited to announce that an important update to our preview of PowerShellGet 3.0 is now available on the PowerShell Gallery! This preview release marks the completion of a complete refactor of this module and is a major step towards being feature complete for PowerShellGet 3.0. PowerShellGet 3.0 is a complete re-write of PowerShellGet [&hellip;]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/19114","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/users\/67292"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/comments?post=19114"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/posts\/19114\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media\/13641"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/media?parent=19114"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/categories?post=19114"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/powershell\/wp-json\/wp\/v2\/tags?post=19114"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}