Configuration option to debug or run a script without dot sourcing it

[metablaster]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues to ensure it has not already been reported.

Summary

There are 3 ways to debug (or run) a script In VSCode:

1. Run -> Run Without Debugging
2. Run -> Start Debugging
3. By configuring launch.json and start debugging from action bar.

In all 3 cases a script will be dot sourced and I don't see a way to instruct debugger to call it rather than dot sourcing it.

I didn't notice this behavior until I stumbled upon a problem which you can see on SO:
"Run without debugging" or "Start debugging" giving different result than running script manually

Here is sample code:

$private:PSDefaultParameterValues = @{}
$private:PSDefaultParameterValues.Add("*:ErrorVariable", "+ErrorBuffer")

function Test-Variable
{
    [CmdletBinding()]
    param ()

    "Test-Variable private: '$($private:PSDefaultParameterValues | Out-String)'"
    "Test-Variable local: '$($local:PSDefaultParameterValues | Out-String)'"
    "Test-Variable script: '$($script:PSDefaultParameterValues | Out-String)'"
    "Test-Variable global: '$($global:PSDefaultParameterValues | Out-String)'"

    $ErrorBuffer = $PSCmdlet.GetVariableValue("ErrorBuffer")
    "Count of errors is $($ErrorBuffer.Count)"

    Write-Error -Message "sample error"

    "Count of errors is $($ErrorBuffer.Count)"
    $ErrorBuffer.Clear()
}

Test-Variable

Put it into a script and call it, the result is as expected, "one error", but when you run it with the help of PS Extension the result is unexpected because the script isn't meant to be dot sourced.

Currently it's impossible to debug or run it and have the result you want.
Debugger should not assume a user whishes to dot source a script.

Proposed Design

I propose an option to let user instruct debugger on how a script is to be executed, for example:

"powershell.debugging.executeMode = "call"

// OR

"powershell.debugging.executeMode = "dotsource"

[andyleejordan]

It's not a bad idea at all, thanks for the suggestion!

[ThioJoe]

I also would like this. I use AppLocker so Powershell by default runs in Constrained Language mode. But I have certain scripts, and even certain directories set to allowed in AppLocker. So when actually running those scripts, they are actually running in Full Language mode. However, the Powershell extension only runs by dot sourcing, which won't even let it run in the first place, for example:

PS B:\DemoFolder> . 'B:\DemoFolder\test.ps1'
test.ps1: Cannot dot-source this command because it was defined in a different language mode. To invoke this command without importing its contents, omit the '.' operator.

But when running the script just through a powershell window:

Write-Host "Hello World!"
Write-Host $ExecutionContext.SessionState.LanguageMode

I get:

PS B:\DemoFolder> .\test.ps1
Hello World!
FullLanguage

So it should work, but it can't if it's trying to run by dot sourcing apparently. Without the option to change it, the extension is effectively useless on any device with AppLocker.

[drstonephd]

There is a lot of fuss about honoring preference variables in a module. For example, I use DBATools. I have to use the global scope to silence the module. However, without a script scope, I don't have an easy means to set the preferences for my personal use.

[pheeling]

@andyleejordan Is there an ETA for this feature?

[andyleejordan]

Not currently, sorry. We are swamped with other work right now, but we will get to it eventually!

[andyleejordan]

I'll add that I would be super happy to take a PR for it!

[andyleejordan]

Working on getting this in 🙏

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[metablaster]

@andyleejordan
I appreciate the fix but I'm currently not in position to test it because I've switched to Linux almost a year ago and no longer do anything with PowerShell, I also no longer maintain my old PS project and don't even know where I left off.

I'm sure somebody else can test and confirm the fix.

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[JustinGrote]

@metablaster no worries! I'll be able to confirm it. Thanks so much for your contribution and sorry it took us so long to address it.

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[github-actions]

This issue has been labeled as needing fix verification and has not had any activity a week. It has been closed for housekeeping purposes.