Just some helpful PowerShell
Where to start with powershell
I've build a helper function that anyone can use to get a simple pipeline off the ground and have it prepped and ready for use in Azure Devops. The module can also be found in the PSGallery.
I have not done very robust documentation on this pipeline because its all pretty generic. When working with powershell there are many standards that can, but do not need to be, applied to script or module files but they aren't required. The module above is simply a template that will stamp out the file/folder stucture that is needed for publishing a module with each function broken down for easy of use and portability.
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 (the default path is %appdata%\Code\User\settings.json) you can see what default PowerShell is being used:
"powershell.powerShellDefaultVersion": "Windows PowerShell (x64)"
It's 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 core
The screenshot above is what generally will show up on your windows machine if you use PowerShell on a windows host. PowerShell started to diverge in v6 (AKA PowerShell core) and doesn't natively come on any OS.
For Windows:winget install --id Microsoft.Powershell --source winget
For Mac:brew install powershell
For Linux:snap install powershell --classic
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 it's 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 PS core on the same machine you will get a command line prompt:
In Summary
When working with PowerShell it's 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.
