PSResourceGet: the package manager PowerShell 7.4 ships with

A rename that kept the old ecosystem in view

PSResourceGet is a PowerShell module with commands for discovering, installing, updating and publishing the PowerShell resources like Modules, Scripts, and DSC Resources. The primary language is C#, the licence is MIT, and the default branch is master.

The naming is the first thing to get right. The README notes that PSResourceGet is short for the full name of the module, Microsoft.PowerShell.PSResourceGet, and that the full name is what is used in PowerShell and when published to the PowerShell Gallery. The badge in the documentation header is labelled PowerShellGet, which is a leftover from before the rename rather than a hint that this is the old module.

The history matters for anyone arriving from the old tooling. The README says that if you were familiar with the PowerShellGet 3.0 project, the module was renamed to PSResourceGet, with a link to a blog post about PowerShellGet in PowerShell 7.4 updates. And two separate repositories are named for the older versions: the repository for PowerShellGet v2 is at PowerShell/PowerShellGetv2, and the repository for the PowerShellGet v3, described as the compatibility layer between PowerShellGet v2 and PSResourceGet, is at PowerShell/PowerShellGet.

So there are three codebases in play, and the v3 one exists only to bridge. Anyone migrating an existing script needs to know which of the three they are looking at.

The homepage is the PowerShell Gallery listing for Microsoft.PowerShell.PSResourceGet, and the documentation lives on Microsoft Learn.

Getting the module, and why it is usually already there

The install story is short because in most cases there is nothing to install.

The requirements are PowerShell 5.0 or higher. Beyond that, the install section says PSResourceGet is short for the full name Microsoft.PowerShell.PSResourceGet, that it is included in PowerShell since v7.4, and that you should use the PowerShell Gallery to get the latest version of the module.

So on PowerShell 7.4 or later the module is present out of the box, and the Gallery is where you go for a newer version than the one bundled with your platform. On Windows PowerShell 5.x it is a module you install.

The homepage for the package points at the same Gallery listing, and the documentation badge points at the Microsoft Learn module reference.

There is a small governance point in the README that is worth reading before you file anything. If you would like to open a PR please open an issue first so that necessary discussion can take place, and please open an issue for any feature requests, bug reports, or questions for PSResourceGet. That is a slower route for contributors and a faster route for everybody else, since the discussion happens before code is written rather than after.

The project also has a Code of Conduct, a Security Policy, an owners.txt listing maintainers, and a Notice.txt, which is the pattern you would expect from a module that ships as part of the PowerShell distribution.

Building from source, which starts with an exact .NET SDK

The Contributing Quickstart Guide is precise about the toolchain, and the precision matters.

You get the source from the release page or by cloning the repository, and the guide shows it as a sequence of PowerShell prompts.

  PS > cd 'C:\Repos'
  PS C:\Repos> git clone https://github.com/PowerShell/PSResourceGet

Then you navigate into the local repository directory.

  PS C:\> cd c:\Repos\PSResourceGet
  PS C:\Repos\PSResourceGet>

The build step has a precondition that is stated as a note rather than enforced by the script: please ensure you have the exact version of the .NET SDK installed. The current version can be found in the global.json and installed from the .NET website.

  # Build for the net472 framework
  PS C:\Repos\PSResourceGet> .\build.ps1 -Clean -Build -BuildConfiguration Debug -BuildFramework net472

The exact-version requirement is the kind of detail that saves a day. global.json pins the SDK version, and a different SDK on the machine will either fail the build or, worse, produce output that does not match what the CI pipeline produced. The build script is invoked with -Clean, -Build, a Debug configuration and an explicit target framework, which is the shape of a script designed to be run in a pipeline rather than by hand.

The tree supports that: there is a bootstrap.ps1 alongside build.ps1, doBuild.ps1, buildtools.psd1 and buildtools.psm1, a package.config.json, a nuget.config, and .pipelines/ and .ci/ directories for the automation.

Running the tests, and loading the built module

The functional tests are Pester tests, and the guide gives both the all-tests and single-file invocations.

  PS C:\Repos\PSResourceGet> Invoke-Pester

  PS C:\Repos\PSResourceGet> Invoke-Pester <file-name>

Then comes the step that catches people out. To import the built module into a new PowerShell session, the path differs depending on which PowerShell you are running.

# If running PowerShell 6+
C:\> pwsh
C:\> Import-Module C:\Repos\PSResourceGet\out\PSResourceGet

# If running Windows PowerShell
c:\> PowerShell
C:\> Import-Module C:\Repos\PSResourceGet\out\PSResourceGet\PSResourceGet.psd1

The difference is the file extension. The modern host loads the directory, while Windows PowerShell needs the explicit .psd1 manifest path, because the module was built for the net472 framework as well as the newer targets and the two hosts resolve the module directory differently.

The repository also has a test/ directory, a src/ directory, an Examples/ directory with two documents about finding and installing a repository that provides searching examples, and a tool/ directory. The CHANGELOG.md and the CHANGELOG/ directory suggest release notes are kept per version as well as in aggregate.

The support lifecycle follows the PowerShell release, not the module

This is the part of the documentation that changes how you think about versions, and it is the reason the module has a preview channel at all.

Microsoft.PowerShell.PSResourceGet follows the support lifecycle of the version of PowerShell that it ships in. The example given is that PSResourceGet 1.0.x shipped in PowerShell 7.4, which is an LTS release, so it will be supported for three years.

From that follow three rules. Preview versions of the module, or versions that ship in preview versions of PowerShell, are not supported. Versions of PSResourceGet that do not ship in a version of PowerShell will be fixed forward. And a module version inherits the fate of the platform release it arrived in.

That last point has a practical consequence worth spelling out. If you pin PSResourceGet 1.0.x, you are pinning yourself to the three-year support window of PowerShell 7.4, and you will be on a fixed-forward path the moment that window closes. If you instead track the version that ships with the PowerShell you are running, you get the fixes but you get them on the platform's schedule.

The recent releases show both tracks in the repository. v1.2.0 shipped on 2026-03-11, v1.2.0-rc3 on 2026-02-06, and v1.3.0-preview1 on 2026-05-20. The presence of a release candidate and a preview in the same recent history, alongside the rule that preview versions are not supported, is the clearest statement of the policy: the channel is there, and it comes without a support commitment.

Where PSResourceGet is the wrong choice

There are three boundaries, and one of them is a genuine migration question rather than a limitation of the module.

The first is Windows PowerShell without a way to install it. The requirement is PowerShell 5.0 or higher, so the module works on 5.x, but it is included in PowerShell since v7.4, which means on a locked-down Windows PowerShell estate you are shipping a module to machines yourself. If your estate is 5.x and centralised package deployment is restricted, the built-in availability argument does not apply to you.

The second is the transition itself. The PowerShellGet v3 repository is described as a compatibility layer between PowerShellGet v2 and PSResourceGet, and it exists as a separate project, which tells you the two command surfaces are not identical. A script written against Install-Module and Get-Module in the old world may need review against the PSResourceGet verbs, and that is a review of your own automation rather than something the module does for you.

The third is scope. This is a package manager for PowerShell resources: modules, scripts and DSC resources. It is not a general dependency resolver, it is not a tool for building or publishing your own package, and it does not manage runtime versions of the PowerShell host itself. If what you want is a way to ship a script to a fleet of machines, that is a deployment tool, and a different one.

There is also a practical alternative that needs no migration at all. The older PowerShellGet v2 repository is maintained separately and remains available, and for a script that only needs to install a module from the Gallery on one machine, using the tooling that already exists is often the lower-risk choice than changing the package manager in the same release as the change to your code.

The realistic framing is that PSResourceGet is the forward path, adopted at the pace your fleet can absorb.

Editorial conclusion

Adopt PSResourceGet if you are on PowerShell 7.4 or later and want the package manager that ships with the platform rather than the older PowerShellGet, since the two have different command surfaces. Do not adopt it if you are still on Windows PowerShell 5.x without a way to install it, and do not rely on a preview build for anything you need supported. Before you script against it, check the version you actually have with Get-Module -ListAvailable, and note the last push was on 2026-10-20 with the newest release v1.3.0-preview1 from 2026-05-20.

Frequently asked questions

Official sources

1. License: MIT
2. PowerShell/PSResourceGet on GitHub
3. Project website
4. README
5. Releases