• Windows PowerShell
• Windows PowerShell 5.0

In this article, we explain why PowerShell Studio can run your scripts only in the versions of Windows PowerShell that are installed on local and remote computers.

If you’ve recently upgraded to Windows 10 from Windows 7, 8, or 8.1, you’ll notice quickly that you now have Windows PowerShell 5.0. Depending on your upgrade path and subsequent updates, you might be running any version of Windows PowerShell greater than or equal to 5.0.10240.

Or, you might have installed the shiny new Windows Management Framework 5.0 for Windows 7 SP1, Windows Server 2008 R2, and later versions of Windows client and server.

In either case, when you start PowerShell Studio or PrimalScript, the platform options are now V5 and V2. On a 64-bit machine, you have V5 and V2 options for 32-bit and 64-bit platforms.

What happened to Windows PowerShell v3 and v4?

Well, they’re gone.

When you install a new version of Windows PowerShell, the previous version is automatically uninstalled and is no longer available on that computer.

Can I install multiple versions of PowerShell?

No.

If you try to install an older or newer version of Windows PowerShell, you might be able to replace the current version, but you cannot add. You cannot install any two versions of Windows PowerShell side-by-side or in sequence on the same computer. One PowerShell.exe always overwrites the previous one.

Version 2.0 appears to be an exception to the one-version rule, but it’s really not. Instead, Version 2.0 is included in a special mode in every subsequent version. So, there’s still just one PowerShell.exe. Unfortunately, this special mode is designed for and works only on Version 2.0, because the backward compatibility requirement covers only Windows PowerShell 2.0, not any later versions.

Can PowerShell Studio install new versions of PowerShell?

No. (We’ve tried!)

Because we all need to test our scripts and modules on all versions of Windows, we have tried mightly to find some way to install multiple versions of Windows PowerShell on a single system. We’ve tried all sorts of tricks to package it or isolate it or hide it or squeeze it in. However, Windows and the Windows PowerShell installers prevent it.

Instead, we’ve worked very hard to make it easy for you to run and test your scripts on remote computers, including those running different versions of Windows PowerShell.

Which versions of Windows PowerShell do I have?

If you have Windows PowerShell 2.0, you have only 2.0. If you have a later version of Windows PowerShell, you have your version of Windows PowerShell plus 2.0.

• To find the current version of Windows PowerShell, use the $PSVersionTable automatic variable and its PSVersion property.

• To find all installed versions of Windows PowerShell, run PowerShell.exe with its Version parameter. PowerShell.exe starts a Windows PowerShell session.The Version parameter starts the specified version of Windows PowerShell in the new session. It behaves like a MinimumVersion parameter. If you don’t have the specified version, it starts the version that is greater than or equal to the specified version.

  For example, to get the earliest installed version, I start by specifying version 1. The results show that my earliest version is 2.0. Then, to find the next version, I specify version 3. The result show that my next version is 5.0, so I have 2.0 and 5.0.

  

How do I test on multiple versions of Windows PowerShell?

This is the right question and, fortunately, we have some good answers.

It’s critical to test your scripts and modules on all of versions of Windows PowerShell that you support. Be sure to include a #Requires -Version statement on all shared scripts and modules. This statement makes your supported version intent clear to users.

Here are several common strategies:

• Remote and virtual computers. To test on multiple versions of Windows PowerShell, install different PowerShell versions on your local computer, remote computers, and/or virtual machines.For example, I’m running Windows PowerShell 5.0 on my local computer, but I have a Windows Server 2012 R2 virtual machine that runs Windows PowerShell 4.0 and Windows 7 virtual machine that runs Windows PowerShell 3.0.

  In PowerShell Studio, to run a script on a remote or virtual machine, click Home and, in the Run section, click Remote (Ctrl+R). Enter your remote credentials. PowerShell Studio saves the credentials (even if you close the script or close PowerShell Studio), so the next time you want to run a script on that remote machine, just click Remote or Ctrl+R.
  

  You can debug a script on a remote computer or VM. Click Home and, in the Run section, click the arrow beside Remote, and then click Debug Remotely (Ctrl + B).

  

  You can also import cached information about a remote computer or virtual machine into PowerShell Studio. Then, it’s even easier to run on the selected computers. For instructions, see Developing PowerShell scripts for other machines.

  

• Continuous integration testing. You can set up a series of servers that are designed to test your scripts and modules automatically on a variety of platforms. There are several popular tools to help get you started, including TeamCity and Appveyor.
• Community Build Server. A terrific new resource became available to the PowerShell community in July 2015. The PowerShell.org Community Build Server automatically tests your scripts and modules on all supported versions of Windows PowerShell (v2 and greater) any time that you check a new version into a Git repository or accept a pull request. This great resource is available for any project that uses an open-source license. For instructions, see Community Build Server.

So, you cannot install more than one version of Windows PowerShell on a single computer, but there are still several alternatives to help you run tests on multiple versions.

June Blender is a technology evangelist at SAPIEN Technologies, Inc. You can reach her at This email address is being protected from spambots. You need JavaScript enabled to view it. or follow her on Twitter at @juneb_get_help.