Make sure that SettingFile arg is parsed before we load the settings
- Add ability to parse some setting before console host is created
- Trigger the Parse before the console host is created
- disable snapin loading from loading setting before this point
- re-enable mac logging tests.
Also, fix the following Travis-ci issues:
- make sure the Linux and macOS caches are separate to reduce the size
- update the macOS image to the closest image as used by the official build system (equivalent to VSTS hosted mac builds)
'GetTypeInfo()' were added when porting PowerShell to early version of .NET Core (prior .NET Core 1.0).
Most properties and methods in 'System.Type' were missing at that time. Now the call is not needed anymore and should be removed.
Many error messages in PowerShell currently use a LINQ expression to pass both the name of the error and the message through in the error processing. This PR uses the `nameof` feature to carry the error name/ID and gets rid of LINQ expression reflection, hopefully improving performance, especially in editor scenarios.
Based on standard practices, we need to have a copyright and license notice at the top of each source file. Removed existing copyrights and updated/added copyright notices for .h, .cpp, .cs, .ps1, and .psm1 files.
Updated module manifests for consistency to have Author = "PowerShell" and Company = "Microsoft Corporation". Removed multiple line breaks.
Separate PR coming to update contribution document for new source files: #6140
Manually reviewed each change.
Fix#6073
For PSCore 6, we are only supporting InitialSessionState. The RunspaceConfiguration APIs were already made internal. This PR removes all the code related to RunspaceConfiguration. This also means that some public APIs have changed. Was deciding between leaving the RunspaceConfiguration parameters and throwing Unsupported, but thought it was better to have it a compile-time error. This should simplify the code base.
Remove the code that spins up our own assembly load context. Keep the code that registers our `Resolve` method to the default loader's `Resolving` event, so that we can continue to do special assembly resolution as needed (such as the GAC probing logic needed for consuming FullCLR PS modules).
Essentially, the assembly `Microsoft.PowerShell.CoreCLR.AssemblyLoadContext.dll` is not needed anymore, the remaining code should be moved to S.M.A.dll. However, that will break DSC and other native hosts that are hosting powershell. So this assembly is kept for now.
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.
Root cause: Microsoft.WSMan.Management and Microsoft.PowerShell.Commands.Diagnostics are not put in the default snapin list for win-ops, and thus when a runspace is created using RunspaceConfiguration, those 2 are not loaded as snapins by default, which is a behavior change compared to Nano PS.
Fix: Replace the guard 'PORTABLE' to be 'UNIX' so that they are in the default snapin list when targeting windows platform.
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.
This reverts the `if !CORECLR ... #endif` guard surrounding FullCLR
files by applying the original diff from the `source-depot` branch, thus
the accidentally overwritten BOMs were restored as well.
Ilya