This change moves powershell to .NET Core 2.0. Major changes are:
1. PowerShell assemblies are now targeting `netcoreapp2.0`. We are using `microsoft.netcore.app-2.0.0-preview1-001913-00`, which is from dotnet-core build 4/4/17. We cannot target `netstandard2.0` because the packages `System.Reflection.Emit` and `System.Reflection.Emit.Lightweight`, which are needed for powershell class, cannot be referenced when targeting `netstandard2.0`.
2. Refactor code to remove most CLR stub types and extension types.
3. Update build scripts to enable CI builds. The `-cache` section is specified to depend on `appveyor.yml`, so the cache will be invalidated if `appveyor.yml` is changed.
4. Ship `netcoreapp` reference assemblies with powershell to fix the issues in `Add-Type` (#2764). By default `Add-Type` will reference all those reference assemblies when compiling C# code. If `-ReferenceAssembly` is specified, then we search reference assemblies first, then the framework runtime assemblies, and lastly the loaded assemblies (possibly a third-party one that was already loaded).
5. `dotnet publish` generates executable on Unix platforms, but doesn't set "x" permission and thus it cannot execute. Currently, the "x" permission is set in the build script, `dotnet/cli` issue [#6286](https://github.com/dotnet/cli/issues/6286) is tracking this.
6. Replace the use of some APIs with the ones that take `SecureString`.
7. osx.10.12 is required to update to `netcoreapp2.0` because `dotnet-cli` 2.0.0-preview only works on osx.10.12.
8. Add dependency to `System.ValueTuple` to work around a ambiguous type identity issue in coreclr. The issue is tracked by `dotnet/corefx` [#17797](https://github.com/dotnet/corefx/issues/17797). When moving to newer version of `netcoreapp2.0`, we need to verify if this dependency is still needed.
* Help was incorrectly returning multiple instances of the same help file if it existed under a culture path and the parent was in the search path as well
* updated test to use generated help file rather than an actual one
* Fixed test to have module in $pshome path and casing of en-US culture
* Adding PowerShellHelpFiles package which contains default.help.txt to powershell-win-core
* Adding test case to validate that <pshome>/<culture>/default.help.txt is present. This is done by calling 'Get-Help'
* Updating get-help to skip searching for the help file when the InternalTestHooks.BypassOnlineHelpRetrieval is enable. This way, we force get-help to generate a metadata driven help object, which includes a helpUri that points to the fwlink defined in the cmdlet code.
* Updating get-help -online <cmdletName> tests to not delete the help files. Instead, I've added logic to get-help to not find the help file when the test hook BypassOnlineHelpRetrieval is enable.
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.
Chunqing Chen