Understanding your Powershell session
Where you run matters
When using powershell, the context in which you start powershell changes how it operates. This can be seen most obviously with a simple powershell builtin called $PSVersionTable:
PSVersiontable will print out the version of powershell you are running. If you have multiple versions of powershell installed, you may need to switch the context. With VS Code, you can use CTRL+SHIFT+P and then type “Session” to change the version of powershell in the terminal:
If you look at the VS Code settings.json (default path is %appdata%\Code\User\settings.json) you can see what default powershell is being used:
“powershell.powerShellDefaultVersion”: “Windows PowerShell (x64)”
Its important to know what context you are running in because some things may or may not work because of localized settings. Managing how and where you run your code has a big impact on how errors will present themselves and what will be supported.
Installing on Windows:
What gives with the versions?
Powershell has been around for a long time in the windows space, however powershell 6 and up are cross platform. There are limiting factors to writing cross platform scripts, namely related to .net libraries. A script that is designed for powershell 5.1 (windows) is likely only going to work on windows because of the various .net frameworks that come prepackaged on windows installations. For example, if a powershell script is using pop up forms (windows forms in .net) it won’t work on a linux or mac because the windows forms libraries are not available. Some libraries have also become cross platform and can be found in .net core (versions can change what options you will have available).
What does that look like
When using cross platform modules, you can make things look and act differently depending on the OS or context in which its called. For example, the Get-Credential function when called from a windows powershell terminal will give a pop up:
And when you use a powershell session in VS Code on the same machine you will get a command line prompt:
When working with powershell its important to understand how and where you are planning to run your scripts. The way powershell operates is going to be different based on the version, the context, and the features you have installed on your local machine. Where possible, it is best to include any required DLLs/EXE files you might need and use relative pathing to make your scripts more portable/packable. This can sometimes bloat the size of your code base, but if you don’t include it, a check in the script/module to make sure all dependencies are met is a good idea. This can be done with #requires or .MODULESREQUIRED or by writing up explicit checks in the source to throw tailored errors.