Commit graph

8 commits

Author SHA1 Message Date
Steve Lee b7cb335f03
Update copyright notice to latest guidance (#12190) 2020-03-24 11:08:37 -07:00
Dongbo Wang e1203aa31b
Skip the flaky test 'TestAppDomainProcessExitEvenHandlerNotLeaking' for now (#10827) 2019-10-17 17:39:14 -07:00
Dongbo Wang 60a930c9ba Add test for the even handler leaking fix (#10768)
Add a test for the even handler leaking fix addressed in #10626 https://github.com/PowerShell/PowerShell/pull/10626
The test is added to verify that PowerShell unregister the 'AppDomain.ProcessExit' event handler when a Runspace closes.
2019-10-11 23:34:53 +05:00
Kirk Munro cc0fed479a Add APIs for breakpoint management in runspaces and enable attach to process without BreakAll for PSES (#10338) 2019-09-05 11:30:25 -07:00
Tyler James Leonhardt 13fd3af810 New New-PSBreakpoint cmdlet & new -Breakpoint parameter for Debug-Runspace (#8923)
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`
2019-04-13 19:14:53 -07:00
Paul Higinbotham f3efcab91e Change xUnit RunspaceTests to run sequentially (#8796) 2019-01-30 14:12:26 -08:00
Ilya c857392c34
Fix style issues in xUnit tests (#8465) 2018-12-18 21:11:21 +05:00
Ilya a9f106da58 Move xUnit tests in new folder (#8356)
## Motivation

I have a PR where there are many new xUnit tests.
It would also be useful to create new xUnit tests for public APIs.
The number of xUnit tests will increase and their ordering is required.

## PR Summary

- Move C# xUnit tests in new folder. This allows to put new xUnit tests in directory structure in accordance with directory structure where cs files are.
- Use an xUnit TestCaseOrderer attribute to sequentially process tests for `powershell.config.json`.
- Update README.md
- A race condition was fixed which allowed  to run all XUnit tests in single batch job.
2018-12-13 14:22:07 -08:00
Renamed from test/csharp/test_Runspace.cs (Browse further)