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.
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.
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.
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.
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.
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.
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:
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.
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.