PSResourceGet 1.2.0 - The Module Manager PowerShell Deserves

With the release of PowerShell 7.6 comes an updated version of PSResourceGet — 1.2.0. And if you haven’t made the switch from PowerShellGet yet, now is a great time.

When writing the PowerShell 7.6 post, I had an inner debate with myself: should I just cover PSResourceGet as a section in that post, or give it its own? I ended up going with a separate post, and here’s why — the 7.6 post is about what’s new in the PowerShell engine. PSResourceGet is a different story. It’s about how you manage your modules and scripts, and that’s a workflow change that deserves its own attention. Plus, if you’re searching for information about PSResourceGet specifically, you probably don’t want to scroll through tab completion improvements to find it 😉

What is PSResourceGet?

If you’re still using Install-Module and Find-Module from PowerShellGet, PSResourceGet (full name: Microsoft.PowerShell.PSResourceGet) is its replacement. It’s a complete rewrite in C# that drops the dependency on the PackageManagement module and talks to NuGet directly.

The practical result? It’s significantly faster — roughly twice as fast as PowerShellGet in most operations — and a lot less likely to give you those cryptic errors that PowerShellGet was… known for.

If you’re running PowerShell 7.4 or later, you already have PSResourceGet installed. With 7.6, you get version 1.2.0.

The Command Mapping

The biggest mental hurdle when switching is that the command names have changed. Here’s a quick reference for the ones you’ll use most:

The key concept: everything is a “PSResource” now — modules, scripts, and DSC resources are all treated the same way.

Not ready to switch cold turkey?

If you have existing scripts that still use Install-Module, Find-Module, or other PowerShellGet commands, you don’t have to rewrite them all at once. Microsoft provides the CompatPowerShellGet module — a compatibility layer that intercepts the old PowerShellGet commands and redirects them to PSResourceGet under the hood.

Here’s how to set it up:

# Install the compatibility module on your machine (one-time setup)
Install-PSResource -Name Microsoft.PowerShell.PSResourceGet.CompatPowerShellGet

Once installed, your existing scripts that use the old commands will keep working without any changes:

# This script still works as-is — CompatPowerShellGet maps it to Install-PSResource behind the scenes
Install-Module -Name Az.Accounts

No changes to your scripts needed. The compatibility module sits on whatever machine runs the scripts — your local machine, a build agent, a server — wherever PowerShellGet commands are being called. This gives you time to migrate your scripts to the new PSResourceGet commands at your own pace, without breaking anything in the meantime.

What’s New in 1.2.0

Compress-PSResource

This is the headline feature for anyone who publishes modules. Previously, Publish-PSResource did two things in one step: package your module into a .nupkg file and publish it to a repository. That’s fine for quick publishes, but if you need to sign the package before publishing (which you should for anything production-grade), you were stuck.

Compress-PSResource splits that workflow apart:

# Step 1: Package your module into a .nupkg file
Compress-PSResource -Path .\MyModule -DestinationPath .\output

# Step 2: Sign the .nupkg (using your own signing process)
# ... your code signing step here ...

# Step 3: Publish the signed package
Publish-PSResource -NupkgPath .\output\MyModule.1.0.0.nupkg -Repository PSGallery

If you’re publishing modules through a CI/CD pipeline (like Azure DevOps), this is a big deal. You can now have separate build, sign, and publish stages.

Azure Container Registry Support

PSResourceGet now supports Azure Container Registries (ACR) as a repository type. If your organization hosts private modules in ACR instead of a NuGet feed, you can now register it as a repository and use all the regular PSResourceGet commands against it.

Constrained Language Mode

For those working in locked-down environments where Constrained Language Mode (CLM) is enforced, PSResourceGet now works properly in that context. Prior to 1.2.0, trying to use PSResourceGet in CLM could fail — which was particularly frustrating in environments where CLM was enforced specifically for security reasons, and you needed PSResourceGet to manage the approved modules.

Performance Improvements

Container Registry repositories are now faster thanks to token caching. If you’re using a private registry and noticed things were a bit sluggish, this should help.

Better Error Messages

A few quality-of-life improvements:

• Uninstall-PSResource no longer fails silently when a resource wasn’t found — it actually tells you
• Authenticode check failures now have improved error messages
• OneDrive-related “Access Denied” errors when uninstalling modules have been fixed

Should You Switch?

If you’re still on PowerShellGet: yes. The performance difference alone is worth it, and the command mapping is straightforward. Use the compatibility module if you need a smooth transition.

If you’re already on PSResourceGet 1.1.0: the upgrade to 1.2.0 comes free with PowerShell 7.6, or you can install it from the PowerShell Gallery:

Install-PSResource -Name Microsoft.PowerShell.PSResourceGet

For the full list of changes, check out the release notes on GitHub and the official documentation on Microsoft Learn.

Happy scripting 😊