Vscode-powershell: Add an option to load PowerShell profiles in debug sessions

[LethiferousMoose]

Please fill in these details so that we can help you!

System Details

• Operating system name and version: Windows 10
• VS Code version: 1.8.0
• PowerShell extension version: 0.8.0
• Output from $PSVersionTable:

Name Value
---- -----
PSVersion 5.0.10240.17146
WSManStackVersion 3.0
SerializationVersion 1.1.0.1
CLRVersion 4.0.30319.42000
BuildVersion 10.0.10011.16384
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3

Issue Description

When I launch a debug session, functions defined in my PowerShell profile (C:\Users\\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1) are not detected in the session.

[daviwil]

Currently this is by design but we can certainly add an option for it.

[rkeithhill]

If we provide this functionality I think it should be opt-in. I've been burned before when scripts I wrote worked on my computer because of things I had configured in my profile and failed on other computers with a different (or no profile).

In general I think it is a better practice to not rely on functions/variables/aliases defined in a profile script especially if you plan to distribute the script to others. If that isn't a concern then I think it wouldn't be too bad to have to "enable" a PowerShell extension option.

[daviwil]

Yep, definitely not something to be turned on by default!

[JustinGrote]

You can load a profile script by just putting it as part of your launch.json. I don't think a lot of dev time needs to be spent on this.

[rkeithhill]

@JustinGrote Not too mention I think it will get a lot of folks in trouble when their script/module won't run on somebody else's machine that doesn't execute the same profile commands.

[squatched]

Could this information be added to a README somewhere in the meantime? This information being:

• How to edit launch.json to load the user's profile.
• A brief note explaining why this might trip the user up.

I found this functionality confusing personally. All sessions of PS on my computer behave one way, except for the one I'm debugging in? I understand what you're saying about distributing scripts to other machines but that seems like a small number of use-cases compared to users just wanting to debug a script and getting odd behavior that keeps their scripts from running.

If someone is responsible for maintaining scripts and distributing them, they are probably knowledgeable enough to understand the role their profile plays and that they should be running with -NoProfile when testing their scripts.

Conversely, someone who is just automating some tasks on their machine might not understand these nuances and legitimately have no need to but when they try and debug these tasks, the reliance on their profile is busted and they are unable to use this great tool.

[reddwarf666]

@JustinGrote Would you be so kind to explain how that works? I currently want to automatically load the AWS module and set the AWS Region I want to work in and right now VSCode needs to load these two statements each time I start to run/debug a script.

What I do right now in every script I use AWS PowerShell commands in:

# Check if AWS.PowerShell.NetCore is loaded and if not, load it
if (!(Get-Module AWSPowerShell.NetCore)) {
   Import-Module AWSPowerShell.NetCore
   Set-DefaultAWSRegion -Region eu-west-1
}

I would love if this is either loaded globally in VSCode or that this is not part of my scripts but executed each time automatically by VSCode.

[rkeithhill]

I would love if ... this is not part of my scripts

Why? If your script requires commands from a module then the script should import the module or #requires it e.g.:

#requires -Module AWSPowerShell.NetCore
Set-DefaultAWSRegion -Region eu-west-1

FWIW I believe the next drop will allow this. It will run the debugging in an interactive console that will likely process your profile scripts. Although, that might be opt-in - @daviwil?

I wouldn't want my debug session loading any profiles because I've been burned checking in scripts that work on my machine because of a module I loaded in my profile that other users didn't load in theirs.

[reddwarf666]

Why?

Because a large set of our scripts will run on servers where the AWS PowerShell tools are installed and the cmdlets it contains are just available to all scripts.

Now I do agree with you (and quite possibly redefining our way of thinking, thanks for that) it is safer to have the script check and load everything that is needed, just to make sure you have what you need instead of relying on "should have been there..."

#requires -Module AWSPowerShell.NetCore

This is new to me and, well, awesome! Thanks for that one as well! Simple and elegant.

Darn, I'm almost convinced we should adapt this method from now on, makes sense all round.
Well, makes my question (almost) moot doesn't it? :-)

Still curious to see the implementation (and indeed, should be opt-in) as I like writing one-off and quick test scripts where I don't want to be bothered by doing the right thing and including the #requires and set regions statements. Plus, because the module is found to be not present in the execution stack it will be loaded every time debug the script, a bit of a waste of CPU cycle but...on the the other hand, you are debugging so speed and efficiency is not top priority :-)

I want to thank you for making me look at this differently and teaching me a new trick in the process, very much appreciated!

[rkeithhill]

I want to thank you for ...

No problem.

BTW another option that will be available in the next drop of the extension is that you will be able to write arbitrary script in the "script": setting in the launch.json file. It still has to be a single string, so that won't work so well for a lot of script but should be manageable for running a few ; separated commands.

[SydneyhSmith]

Closing as the integrated console experience does run profiles