- Added OutputType attribute.
- Cmdlet adds the PSExtendedError typename and removes Exception and ErrorRecord typenames so that the formatting is used. The formatter then removes PSExtendedError and puts back the original typename so that $Error should be the same before calling Get-Error.
- While testing, had to make some changes to how InvocationInfo is retrieved so that ParseException which contains a nested ErrorRecord which as InvocationInfo is handled correctly.
- Combined Exception and ErrorRecord formatter into one.
Prior to this change, Group-Object -AsHashtable -CaseSensitive would give a key duplication error when given entries that only differ by casing. This was due to always using a case-insensitive hashtable, despite the request for -CaseSensitive behaviour.
ConciseView shows MyCommand as the prefix to the error message, but for a scriptblock, MyCommand is the whole scriptblock. Fix is to use CategoryInfo.Activity if available first. Also handle case where it's a script function by seeing if it's a command and showing MyCommand in that case rather than the Activity.
* Add -SkipHttpErrorCheck to web request cmdlets
The -SkipHttpErrorCheck flag causes web request cmdlets
(Invoke-WebRequest and Invoke-RestMethod) to ignore HTTP statuses that
are error statuses and treat them as successful requests. This allows
users to handle the responses using their own error handler and gives
them access to the full, unmodified response body and headers.
* Add -ResponseStatusVariable to Invoke-RestMethod
This allows the user to specify a variable to set to the integer value
of the respons's status code, Analogous to using
-ResponseHeadersVariable to retrieve the headers of the response. This
can be used to distinguish error messages from success messages when
used with -SkipHttpErrorCheck.
* Fix coding-style error
The summary for the SkipHttpErrorCheck property didn't conform
to style guidelines. This changes the summary to start with
"Gets or sets".
* Add tests for -SkipHttpErrorCheck
This flag supresses terminating errors on web cmdlets.
The tests are written to check that it properly
supressed the errors.
* Add test for -StatusCodeVariable
Th -StatusCodeVariable parameter specifies an output
variable for the status code with Invoke-RestMethod.
This test makes sure it functions properly.
* Fix typos and style for -SkipHttpErrorCheck tests
Variables had different cases from each other and some parameter
names were lower case.
* Fix typos and style for -StatusCodeVariable test
Variables had different cases from each other and some parameter
names were lower case.
* Add failure tests when missing -SkipHttpErrorCheck
These tests ensure that Web Cmdlets fail when -SkipHttpErrorCheck
is missing.
* Clean up tests for -SkipHttpErrorCheck
Per discussion on the pull requests. This commit fixes up
style problems with the tests for -SkipHttpErrorCheck.
* Add more status tests for -StatusCodeVariable
Previously, the -StatusCodeVariable flag in Invoke-RestMethod
only had tests for 200 status. This commit adds tests for 404
and 500 statuses and removes -SkipHttpErrorCheck from the 200
check.
* Fix response body in -StatusCodeVariable test
The test was copy/pastes from the 200 status test. The body
indicated success. This commit fixes that so it is also an
error indicator.
ConvertTo-Json doesn't allow $null to be passed in even though it can be valid resulting json. Fix is to remove the check that the input is not null. NewtonSoft.Json handles it just fine.
`Read-Host` calls into `$Host.UI.Prompt()`. However, this method is also used when the host prompts for mandatory parameters that aren't provided. The method expects to be called when given a `FieldDescription` and if the input starts with `!` it enters `CommandPromptMode`. In this mode, you can type `!?` to request help, for example. However this mode is not something you can use via `Read-Host` (only if calling `$Host.UI.Prompt()` directly passing in a well constructed `FieldDescription`). When using `Read-Host -Prompt`, the cmdlet creates a `FieldDescription` where the name is the prompt and the rest of the properties are empty.
The fix is that if `Label` is empty, we can assume it's being called from `Read-Host` rather than being called to prompt for a mandatory parameter and thus not enter `CommandPromptMode`.
This PR does 4 things:
* Adds a new cmdlet `New-PSBreakpoint` which creates new `Breakpoint` objects and writes them to the pipeline
* Adds a `-Breakpoint` parameter to `Debug-Runspace` which will receive `Breakpoint` objects
* Makes the constructors for `*Breakpoint` public for use with the API
* Makes `Debugger.GetBreakpoint(string id)` and `Debugger.GetBreakpoints()` public since `SetBreakpoints` is public
Note: `New-PSBreakpoint` and `Set-PSBreakpoint` (which already exists) are similar... but `Set-PSBreakpoint` also sets the breakpoints in the _current_ runspace. This is not ideal if we want to set breakpoints in a _different runspace than the current one_.
## PR Context
The "Attach to process" debugging experience in the PowerShell extension for VSCode is _ok_ but it's not great.
The reason it's not great is due to the `BreakAll` feature of PowerShell debugging which, when you run `Debug-Runspace`, will break at the first piece of code that gets run. This is not ideal when you "Attach to process" _and then_ run your code in the other runspace.
Today, the experience drops you in `PSReadLine`'s psm1 if PSRL is available or in the vscode PowerShell helper psm1.
It's unexpected for the user and not ideal.
This PR will allow the extension to pass in the breakpoints that need to be set initially with `BreakAll` turned off for none of this silly behavior.
### Silly behavior example
If you want a repro, try this:
PowerShell instance 1:
```
Enter-PSHostProcess -Id $otherprocesspid
Debug-Runspace 1
```
PowerShell instance 2:
```
./runfoo.ps1
```
Note that you end up NOT `runfoo.ps1`
Steve Lee