Debug a module with "using module" using launch.json after version 2021.12.0 not working, problem added ".{}"?

[hwschneiders]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

I am experiencing a problem with debugging my own modules by help of "using module xxx" in launch.json and calling classes inside the module. I think by pressing [F5] the module should be loaded but I got a error message.
This was working up to version 2021.12.0 .
Problem seems to me while pressing [F5] there is .{} added, so "using module xxx" could not be used directly in launch.json anymore. Is there a workaround in the file launch.json possible or maybe a setting in preferences(to get rid of .{})? I'm showing also my current workaround, but it's bad.

PowerShell Version

Both PS 5.1 and 7 have issues.

Name                           Value
----                           -----
PSVersion                      7.2.6
PSEdition                      Core
GitCommitId                    7.2.6
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Name                           Value
----                           -----
PSVersion                      5.1.17763.2931
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.2931
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Visual Studio Code Version

1.70.2
e4503b30fc78200f846c62cf8091b76ff5547662
x64

Extension Version

I'm working with two versions(two scenarios), latest:
ms-vscode.powershell@2022.7.2
and working one:
ms-vscode.powershell@2021.12.0

Steps to Reproduce

First steps are the files needed for both scenarios
1.) Create folders (I'm using windows) c:\test\testUM
2.) Add File testUM.psm1 in folder of step 1
Content:

class TestClass{
	[void]doSomeWork(){
		write-host ""working;
	}
}

3.) add launch.json in folder c:\test\testUM.vscode (using vscode or manual)
Content:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "PowerShell",
            "request": "launch",
            "name": "working till 2021.12.0",   
            "args": [
                "'.\\test\\testUM';$y=[TestClass]::new();$y.doSomeWork();",
            ],
            "script": "using module ",
            "cwd": "${workspaceFolder}..\\..\\..\\"
        },
        {
            "type": "PowerShell",
            "request": "launch",
            "name": "also working till 2021.12.0",   
            "args": [
                "$y=[TestClass]::new();$y.doSomeWork();",
            ],
            "script": "using module '.\\test\\testUM';",
            "cwd": "${workspaceFolder}..\\..\\..\\"
        },
        {
            "type": "PowerShell",
            "request": "launch",
            "name": "workaround for newer Version, tested with 2022.7.2 (also working in 2021.12.0)",   
            "args": [
                "",
            ],
            "script": "import-module '.\\test\\testUM\\debugHelper';",
            "cwd": "${workspaceFolder}..\\..\\..\\"
        }
    ]
}

4.0) Note - this is a current workaround to get debug working - could be skipped
4.) in new folder C:\test\testUM\debugHelper add file debugHelper.psm1
Content:
using module c:/test/testUM; #using module ./test/testUM; only working in windows powershell not in 7.2
$y=[TestClass]::new();$y.doSomeWork();

Scenario 1 (ms-vscode.powershell@2021.12.0)
start debug all 3 entries, all of them are working, see visuals scenario1 debugging
Scenario 2 (ms-vscode.powershell@2022.7.2), see visuals scenario2 debugging
start debug all 3 entries, only the last entry is working (workaround for newer Version...)
I added the last case one only to show that it could be debugged with a workaround. That implies adding an extramodule for each module that should debugged - this should not be needed! launch.json should cover that.

Note:
In settings I activate Create Temporary Integrated Console
In Version 2022.5.0 there was a problem with this setting but this was solved in a later version.
Powershellversions (5.1 and 7.2) behave the same for results shown. In 5.1 there was a shortcut in debughelper.psm1 command using module ./test/testUM; was ok, this was not working in 7.2, so I used absolute path c:/test/testUM; to get identical results in both versions.

Visuals

Files for both scenarios:
launch.json

testUM.psm1

debugHelper.psm1

Debug all 3 Options

Debugging Scenario 1 results: (using version: 2021.12.0)
1.)

2.)

3.)

Debugging Scenario 2 results: (using version: 2022.7.2)
1.) (Ok in new version I have to write it together, so step 2 will solve it)

2.) (this case is the problematic one)

3.) (workaround not preferable)

Problem (my opinion) in a nutshell:

Logs

No response

[andyleejordan]

Hi there,

So I think I see what's going on. You're placing actual in-line script code in the script argument of launch.json; this means that the launch configuration is going to launch an untitled script, which in order to support breakpoints while debugging untitled scripts, means it must be wrapped in a script block. Before we figured out how to fix that bug, we temporarily stopped wrapping the script (which is the behavior you see in v2022.12.0). However, the intended and by-design nature now is that untitled scripts can be debugged with breakpoints, which necessitates the behavior you see now. If you want to run without the wrapping script blocks, set the script parameter to a file path. (I think you figured this out as your work-around).

Thanks for your understanding!

[andyleejordan]

Also see #3655.

[andyleejordan]

Also, I think you could accomplish what you're trying to do by setting up your in-line script to accept an argument (in this case, a second script block) so that the argument passed to the in-line script is used.

[hwschneiders]

Hmm the problem with the wrapping is that the using module could not be used Documentation
"The using statements must come before any other statements in a script or module. No uncommented statement can precede it, including parameters."
So this must always be the first statement in execution, it could not be used in wrapping, because it's to late.
General my idea was to use the script parameter for loading the module - its class, while I'm using the parameter args to debug details in the class. So difference in case 1 and 2 is everything which is specific to a debug case is in parameter args, while script is used for using module or adding per dot (not shown here)
But I found another workaround to get it work in script - maybe there are other persons using it that way ;)...
launch.json:
{
"type": "PowerShell",
"request": "launch",
"name": "next try5",
"args": [
"",
],
"script": "Invoke-Expression -Command "using module '.\test\testUM';"; $y=[TestClass]::new();$y.doSomeWork();",
"cwd": "${workspaceFolder}..\..\..\"
}
by help of invoke expression the problem with execution order is gone and it's working.
andschwa thanks for your input.

[andyleejordan]

Ah, brilliant!