Please feel free to provide feedback or file bugs here.

Scripts need better isolation from the user's global session state

Votes from Connect: 4

Original Date Submitted: 11/28/2015 5:59:49 AM

********Contact Information********
Handle: Keith Hill MVP
Site Name: PowerShell
Feedback ID: 2065573

Problem Description:
Right now it is too hard to write a 100% reliable script that can run in any particular user's PowerShell console. The crux of the problem is that global session state is so varied amongst individual users it is hard to anticipate all possibilities such as:

•Command proxies
•Imported (auto or explicit) modules that implement the same named command (but semantically different)
•Redirected aliases
•Defined variables you weren't expecting to be defined
•Removed globals you were expecting to be defined
•Already loaded module (but wrong version)

I have seen this issue with an early install script for the powershell-vscode extension for VSCode. The script uses the v5 Expand-Archive command to extract a zip. Seems very reasonable but the script fails for anyone who has the PSCX module installed because PSCX has an Expand-Archive command that uses different parameter names. It is unreasonable to expect script authors to anticipate all these potential variations of global session state. One workaround I have resorted to, is to run all scripts I get from someone else in a new PowerShell session loaded with -NoProfile. This helps but really, I shouldn't have to do that.

IMO it is pretty rare for a script to require anything from the global session state. And if it does require it, it would be better for the script to somehow declare what it needs (usually it's a global variable). Far more often, I want to write my scripts with some sort of #Requires NewGlobalSessionState directive that tells PowerShell to not use **any** of the **user's** global session state. With this, I'm stating that I will import every module that I need and that I specifically don't want to use any of the modules that happen to already be loaded by the user. Command resolution should be based on what the script imports - nothing else. Ditto for alias resolution. Yeah I know I shouldn't be using aliases in my script but I don't want a user redefining the Where alias to break my script.

My understanding is that the PSDefaultParameterValues behavior in a script was changed for V5 to address this sort of issue - user's global session state breaking scripts. The value of PSDefaultParameterValues is cleared for script scope. I think this concept (cleared for script scope) needs more consideration and should be applied to way more than just PSDefaultParameterValues.

Product Studio item created by Connect Synchronizer due to creation of feedback ID 2065573 (

Repro Steps:

Internal BugId: 16016

3 votes
Sign in
Password icon
Signed in as (Sign out)

We’ll send you updates on this idea

AdminJoey Aiello [MSFT] (Program Manager, Windows Server) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)

Feedback and Knowledge Base