We recently spent a lot of time around the office discussing profiles in Windows PowerShell. Actually, to be more specific, we were discussing snap-ins, those DLLs that bring new and wonderful cmdlets to your PowerShell environment.
There are three basic ways of getting a snapin loaded into PowerShell: By manually loading it (via Add-PSSnapin), by loading it your profile (by putting a call to Add-PSSnapin in the profile), or by manually loading it and then exporting a console (and then running that exported console in the future, rather than the default PowerShell shortcut).
The first way is obviously not great, as it’s very repetitive – you have to redo this each time PowerShell loads. The second method – the profile – isn’t repetitive. Neither is the third method.
All of this came out of a discussion on how to make PrimalScript provide code-hinting for added cmdlets, not just the core cmdlets. Technically, PrimalScript can do this already. However, PrimalScript actually hosts PowerShell itself – it doesn’t just run PowerShell as a command-line application. So, when PrimalScript loads up, it just gets the default PowerShell cmdlets – no snap-ins. Currently (and I’m talking about PrimalScript Enterprise and Pro, v4.1.532), PrimalScript doesn’t execute any profiles. If your scripts use any non-default cmdlets, then your script needs to explicitly load those via Add-PSSnapin. And, because the cmdlets aren’t present in the shell when PrimalScript starts, PrimalScript doesn’t “see” anything but the default cmdlets – which means no PrimalSense code-completion.
What will probably happen in some future version of PrimalScript is that it’ll give you the option of running your profiles when it loads up PowerShell. That way, any snapins added by your profile will be present when PrimalScript pulls a list of available cmdlets. That means any scripts you write will be able to use your snapins, and PrimalScript will be able to give you code-hinting and other PrimalSense help for those snapins.
However… there’s not a lot of guidance from Microsoft on how you’re supposed to add snapins. PrimalScript will exploit the profile technique because, practically, it’s the only thing it can do. However, if you’re decided to leave your profiles empty, and instead export a new PowerShell console shortcut whenever you add snap-ins… then PrimalScript will never “see” those snap-ins, and won’t be able to help with them. That’s because PrimalScript isn’t launching PowerShell.exe via a shortcut; it’s actually hosting the PowerShell DLL internally, just as PowerShell.exe itself does.
Most non-Microsoft tools will have to utilize the profile technique of adding snap-ins. However, profiles have a downside: Although PowerShell can be configured to only run profile scripts which are digitally signed, we all know good and well that you’re going to set it to not require a signature. Bad Idea. Why? Because PS1 files are just text files: If you have a non-signed profile, then it’s possible for a malicious script or program to modify your profile. Next time you run PowerShell, malicious code that you didn’t even know existed would execute under your credentials. Had you signed the file, the malicious modification would have “broken” the signature, preventing the profile script from running and protecting you; this is a prime example of why profiles should always be signed and why PowerShell should only be configured to run signed scripts.
Because of the potential vulnerability of profiles, and because I know jolly well that everyone’s going to turn the digital signature security off, I’d prefer – from a security viewpoint – the console method of adding snap-ins. Sadly, that breaks what an editor like PrimalScript can work with.
The moral of the story? Use profiles to add snap-ins, but digitally sign them. Seriously – if you turn off and don’t use the digital signature security, you’ll eventually get what you’re asking for: Trouble.
