Our private implementation of FailFast was likely introduced
when each individual application needed it's own code to
get Watson reports. The CLR takes care of this for us now,
so we don't need our implementation.
Our method CheckForSevereException was also introduced in
the early days of the CLR - the exceptions it was checking
for aren't actually raised the CLR anymore, they just FailFast.
I removed them as there is a tiny bit of overhead (in code size)
and also in the generated code, e.g. dynamic sites called the method.
In PS Core on windows, we try to locate the default web browser and use it for online help. If we cannot find the default web browser (in NanoServer/IoT), we error out.
Also includes these bugfixes:
- WSManConfigProvider.GetHelpMaml: Tried to load XML from
MemoryStream that was created from file name string. Use XmlReader
instead.
- WSManConfigProvider.GetHelpMaml: Use Path.Combine instead of
platform-specific directory separator character.
- WSManConfigProvider.GetHelpMaml: CmdletHelpPath MAML XML element
attribute `ID` name casing seems inconsistent with other help.xml
files. XPath 1.0 does not support case-insensitive expressions,
use both `id` and `ID` in query.
- Add Pester test to verify that Get-Help shows provider-specific help.
Fixes#2088
Mostly using R# to automatically refactor, with some manual
fixups where it wouldn't work automatically (e.g. xml comments
on fields) or some it seemed to miss.
Some minor code reformatting was also done on properties near
other stuff I was manually inspecting.
I (Jason Shirk) ran https://github.com/dotnet/codeformatter with the default rules, basically:
codeformatter /nocopyright "/c:DEBUG,UNIX,CORECLR" @files.rsp
This caused a few problems building, which were fixed up manually.
Notable changes:
`this.` is removed unless needed to disambiguate.
private instance fields are renamed to have a `_` prefix.
private static fields are renamed to have a `s_` prefix.
I left some projects alone (like PackageManagement) and also left some generated code alone.
These currently fail at runtime on Nano, and will continue to do so. But
this implements these much needed cmdlets for Open PowerShell.
If there is a way to determine that PowerShell is being run on the Nano
OS at runtime, then we could instead throw a platform unsupported
exception, but this cannot be based on the target compilation framework,
as .NET Core is shared for both Nano and Windows.
While Windows will automatically open a URL used as a process by
launching a browser, OS X needs to use `open <URL>`, and Linux needs to
use `xdg-open <URL>` (the most distribution-independent way).
Resolves#802.
Jason Shirk