NanoServer is missing some console APIs that PSReadline uses which causes PSReadline to not be usable on NanoServer docker images.
For the missing font/display APIs, the fix is to assume all characters use 1 cell which is not always correct for some languages.
For the missing keymap APIs - there is no workaround in this change and a small number of key bindings don't work, there is an open issue to track those.
Fixes#3463
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.
- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400
The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
* Add OpenCover PS Module to collect code coverage
OpenCover PS Module helps is collecting Code Coverage using the OpenCover
toolset. The module helps in comparing two code coverage runs as well.
* Change OpenCover.psd1 to ASCII
* Fix an error in path for OpenCover
Fixed an error on path for OpenCover. Also used ZipFile class instead of
cmdlet as it might not be available on CI system.
* Convert module to be Powershell v4 compliant
Changed implementation from classes to PSObjects and implemented
Expand-ZipArchive.
* Added CodeCoverage as a configuration to project.json files
Added CodeCoverage as the new configuration for all the project.json
files. When Start-PSBuild is executed with configuration as CodeCoverage,
we change the degubType to 'full' as required by OpenCover toolset.
Also made changes to appveyor.psm1 to build a CodeCoverage package on
daily builds and publish it as a zip.
* Addressed code review comments
Changed from Add-Member to use pscustomobject type accelator. Removed
[gc]::collect.
* Added explicit garbage collection
* Addressed code review comments
- Make sure that the build Start-PSPackage gets is not a code coverage
build
- Add debugType = full for FullCLR
- Remove configurations from PackageManagement files as it is not needed.
- Build CodeCoverage build first in AppVeyor.
* Resolve merge conflict
* Fix indentation
* Fix newline at end of file
* Added command discovery for locating OpenCover.console.exe
Before this commit there were three spellings, one of which was a typo,
one was a variant spelling, and one was the dominant spelling.
Microsoft generally uses Hangul for its enums:
https://msdn.microsoft.com/en-us/library/cc250412.aspx
And this is the dominant spelling in general and as used in web browsers.
* spelling: comments in src/Microsoft.Management.Infrastructure.CimCmdlets
* spelling: comments in src/Microsoft.PackageManagement.ArchiverProviders
* spelling: comments in src/Microsoft.PackageManagement.CoreProviders
* spelling: comments in src/Microsoft.PackageManagement.MetaProvider.PowerShell
* spelling: comments in src/Microsoft.PackageManagement.MsiProvider
* spelling: comments in src/Microsoft.PackageManagement.MsuProvider
* spelling: comments in src/Microsoft.PackageManagement.NuGetProvider
* spelling: comments in src/Microsoft.PackageManagement.PackageSourceListProvider
* spelling: comments in src/Microsoft.PackageManagement
* spelling: comments in src/Microsoft.PowerShell.Activities
* spelling: comments in src/Microsoft.PowerShell.Commands.Diagnostics
* spelling: comments in src/Microsoft.PowerShell.Commands.Management
* spelling: comments in src/Microsoft.PowerShell.Commands.Utility
* spelling: comments in src/Microsoft.PowerShell.ConsoleHost
* spelling: comments in src/Microsoft.PowerShell.Core.Activities
* spelling: comments in src/Microsoft.PowerShell.CoreCLR.AssemblyLoadContext
* spelling: comments in src/Microsoft.PowerShell.CoreCLR.Eventing
* spelling: comments in src/Microsoft.PowerShell.Diagnostics.Activities
* spelling: comments in src/Microsoft.PowerShell.GraphicalHost
* spelling: comments in src/Microsoft.PowerShell.LocalAccounts
* spelling: comments in src/Microsoft.PowerShell.Management.Activities
* spelling: comments in src/Microsoft.PowerShell.PSReadLine
* spelling: comments in src/Microsoft.PowerShell.PackageManagement
* spelling: comments in src/Microsoft.PowerShell.ScheduledJob
* spelling: comments in src/Microsoft.PowerShell.Security.Activities
* spelling: comments in src/Microsoft.PowerShell.Security
* spelling: comments in src/Microsoft.PowerShell.Utility.Activities
* spelling: comments in src/Microsoft.PowerShell.Workflow.ServiceCore
* spelling: comments in src/Microsoft.WSMan.Management.Activities
* spelling: comments in src/Modules
* spelling: comments in src/Schemas
* spelling: comments in src/libpsl-native
* spelling: comments in src/powershell-native
* spelling: comments in build.psm1
* spelling: comments in src/System.Management.Automation/CoreCLR
* spelling: comments in src/System.Management.Automation/DscSupport
* spelling: comments in src/System.Management.Automation/cimSupport
* spelling: comments in src/System.Management.Automation/commands
* spelling: comments in src/System.Management.Automation/engine/Modules
Due to virtual key codes on Windows, simple chords like Ctrl+] are not
recognized as such. Instead, the ConsoleKey is Oem6, and the KeyChar is
an control code.
CHAR_INFO has 4 bits for ConsoleColor. On Linux, ConsoleColor is sometimes -1 (unknown),
which is a 17th possible value for ConsoleColor, which can't be represented in CHAR_INFO.
To fix this, I've introduced a bigger type that gets converted to CHAR_INFO when necessary.
A similar change was made to the Source Depot fork of PSReadLine, and
the behavior is depended on in the ConsoleHost. The host always attempts
to load PSReadLine, because a future version of PSReadLine will support
redirected input/output, and until then, PSReadLine must throw so that
the host correctly falls back to Console.ReadLine().
Steve Lee