A guide for developers who need to work with older module versions

Sometimes you update PnP.PowerShell to the latest version, and suddenly a script stops working. Maybe a cmdlet changed behavior, a regression was introduced, or you simply need to test something against an older SharePoint environment.

I had a problem where version 3.1.0 of PnP.PowerShell did not get all the client side pages when I tried to run:

Get-PnPSiteTemplate -Out pagestemplate.xml -Handlers PageContents, Pages -IncludeAllClientSidePages

It worked before when I had version 2.12.0, but there were other stuff I needed from the 3.1.0 version. The good news:
PowerShell supports having multiple versions of the same module installed side-by-side.

This means:

• You can install older versions of PnP.PowerShell without overwriting the latest one
• You can load a specific version whenever you need it

This guide shows how to:

1. See which versions are installed
2. Install an older version
3. Load a specific version in your session
4. Switch back to the latest version
5. Avoid common pitfalls

1. Check which PnP.PowerShell versions are installed

Get-InstalledModule PnP.PowerShell

This lists all versions installed on your machine.

Example:

3.1.0
2.12.0
2.4.0

2. Check which version is currently loaded

To see which version PowerShell has actually loaded into memory:

Get-Module PnP.PowerShell

If the command returns nothing, it simply means no PnP commands have been executed yet in this session.

3. Install an older version (without overwriting the latest)

Want to install version 2.12.0 in addition to your current version?

Install-Module PnP.PowerShell -RequiredVersion 2.12.0

PowerShell stores each version in its own folder, such as:

…\PnP.PowerShell\3.1.0\
…\PnP.PowerShell\2.12.0\

Nothing is removed or replaced — all versions coexist.

4. Load a specific version in a PowerShell session

If you want to work with version 2.12.0, follow these steps:

Open a new PowerShell window

(Important! See the pitfalls below.)

Import the specific version

Import-Module PnP.PowerShell -RequiredVersion 2.12.0 -Force

3️⃣ Verify it

Get-Module PnP.PowerShell

Your session is now using that version.

5. Switch back to the latest version

Simply close the window and open a new PowerShell session.
Then run any PnP command, for example:

Connect-PnPOnline …

PowerShell will automatically load the newest installed version.

Common Pitfalls

Pitfall 1: “Assembly with same name is already loaded”

This appears if you try to load an older version after a newer version has already been loaded in the same session:

Import-Module: Assembly with same name is already loaded

Solution

Start a new PowerShell window, then import the older version before running any PnP commands.

PowerShell cannot unload a module’s DLL once it has been loaded.

Pitfall 2: Get-Module returns nothing

This just means the module hasn’t been imported yet.
Once you run your first PnP cmdlet, it will appear.

Pitfall 3: “The wrong version loads even though several are installed”

PowerShell always loads the highest version number, unless you explicitly import a specific one:

Import-Module PnP.PowerShell -RequiredVersion X.Y.Z

6. Removing an old version (optional)

Uninstall-Module PnP.PowerShell -RequiredVersion 2.12.0

Summary

Conclusion

Switching between PnP.PowerShell versions is straightforward and safe.
By installing historical versions side-by-side, developers can quickly test, debug, or run scripts that rely on older behavior — without impacting their main setup.