* AlternateStreams support relies on pinvoke to win32 APIs which don't work on non-Windows and produces errors about not loading a DLL in the case of copy-item
* Address PR feedback, remove -Stream parameter for Unix added new -stream tests
* if/def out alternate stream syntax checks not applicable to Unix
To improve code clarity and give better error messages when using ValidateRange, you can now specify:
```
[ValidateRange(ValidateRangeKind.Positive)]
```
instead of
```
[ValidateRange(1, 2147483647)]
```
Valid kinds are:
Positive
Negative
NonPostiive
NonNegative
Make `System.Management.Automation references` to package `System.Security.Permissions`, which brings back `SecurityZone` and `System.Security.Policy.Zone`.
* address static analysis issues
- remoteRunspaces is not used TFS:10618323
- not checking return value of ResumeThread() TFS:10618344
* fixed magic number use
* changed magic number to Uint.MaxValue
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.
* Caching the parent id of the current process
In certain scenarios, like a domain joined machine with an executionpolicy set via GPO, a lot of checks are done for the ExecutionPolicy, and this is in the hot path.
* Caching HasGPScriptParent.
It is expensive to determine if a script was run as a result of applying a group policy. This does not change during the lifetime of a process.
This only affect the scenario when an execution policy has been set by a group policy.
* Using available Microsoft.PowerShell.ProcessCodeMethods.GetParentPid
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.
- Fix incorrect handling of 'GetCurrentProcess()' API return value in 'IsWow64()' function (MainEntry.cpp)
- Remove unused INVALID_HANDLE_VALUE field from 'ProcessNativeMethods' class (Process.cs)
There are cases like using PowerShell via Puppet where the account being
used does not have a home directory. Updated PowerShell to use a process
specific temporary directory if HOME, CONFIG, CACHE, and DATA directories
are not available. Temporary directory is removed when last runspace
is disposed.
Based on the conclusion in discussion #3248, this PR fix "OEM" and "Default" encoding in powershell.
1. OEM -- We need an internal fix because .Net Core has no "OEM" encoding.
The fix gives the following PowerShell Core behavior on "OEM" encoding:
- on Windows - as Windows PowerShell based on GetOEMCP() and legacy encodings (System.Text.Encoding.CodePages)
- on Unix - the same as default encoding in PowerShell Core
2. Default -- We need internal fix because CoreFX `Encoding.default` for all platforms is UTF8.
Until we complete the `Encoding RFC` we should restore behavior as in Windows PowerShell.
The fix gives the following PowerShell Core behavior on "Default" encoding:
- on Windows - as Windows PowerShell based on GetACP() and legacy encodings (System.Text.Encoding.CodePages)
- on Unix - UTF-8 without BOM (We are expecting that the same will be [in CoreFX](https://github.com/dotnet/coreclr/issues/10643))
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.
* Fixes#2534 by replacing expensive WMI query with Win32 API calls
* fix break on unix build
* added tests for #2535
* although test passed, fixing exception that shows up
* fixed Describe text
* addressing code review feedback
* addressing review feedback to comment on why sleep is needed
added check that test processes are created before we try to kill them
* fixed test to timeout and pending fix for #2561
This exception is no longer used by PowerShell, so it has been removed.
It is a public api, so removing it risks breaking somebody. Nobody has any reason
to catch or throw this exception, so it seems safe to remove, but I decided to
be conservative and keep it for Windows PowerShell. It seems safe enough to remove
in Nano.
Steve Lee