Description
Ugh. It appears that this crashes the host because VSCode asks for "sourceReference" info with a null value which crashes during JSON deserialization. We could probably fix the stackFrame's source to return a non-null Name (we don't have a Path for this outer scope). However we would like to replace AddScript with AddCommand.AddParameter/AddArgument. And that would eliminate the extra scope!
I have prototyped this and there are several problems. First, we would no longer accept a "single" string containing all arguments. I don't want to get into the business of fully replicating PowerShell's argument parser. So users will have to provide each parameter/argument in a separate string in the args string array. I've identified several places where that breaks down e.g switch parameters:
"-SwitchParameter", "value"
Passing switch parameters is tricky. They really need to be at the end of the args array after all other parameters & args. This is because we don't know if "value" is supposed to be an argument for the -SwitchParameter of if it is meant to be a positional (or extra) argument. We "could" require the user to always supply an argument for switches but the AddParameter API wants a .NET boolean value as the arg. We only get strings from VSCode. In the args, I've tried "$true", "1", etc but I get the error:
Cannot process argument transformation on parameter 'force'. Cannot convert value
"System.String" to type "System.Management.Automation.SwitchParameter".
Boolean parameters accept only Boolean values and numbers, such as $True, $False, 1 or 0.
Keep in mind I don't really want to know if the parameter is supposed to be a switch or not so I again I don't want to get into the business of specia casing values (converting string "$true" to .NET boolean true).
The third issue is handling argument arrays e.g. -p1 foo,bar,baz. How does the user specify that in the "args": field in launch.json. Who knows what else will crop up.