The `Get-Process` cmdlet cannot be used for these types of tests due to
security constraints on OS X.
These tests are about to be re-written soon anyway, so the simple fix
was to use another cmdlet.
Instead of using `dotnet publish`, we can use `dotnet build` and the new
`netcoreapp1.0` framework with a new dependency on
`Microsoft.NETCore.App` to generate output that does not include the
runtime, but can be run anywhere (given the installation of the
runtime).
While we cannot yet adopt a dependency on the shared host until .NET
Core RTM, we are forced to switch to this system anyway because the
latest RC3 packages and CLI do not support `netstandardapp1.5`. See
dotnet/cli#2482.
Thus we're in an in-between state where we have to use `netcoreapp1.0`,
but cannot use `"Microsoft.NETCore.App": { "type": "platform" }` to
utilize the shared host, as we need to continue to ship our host.
Without specifying "platform", we retain the status quo with respect to
build steps and outputs.
Additionally, there is no longer a good reason to use the RC3 packages,
and it has been advised we switch to RC2 since the
`Microsoft.NETCore.App` is only available for RC2. We must update
packages because our current version can no longer be debugged.
**Added -Pending:$flags for Linux and OSX to set-content and add-content
tests that expose dynamic variable file issues on these platforms
(https://github.com/PowerShell/PowerShell/issues/891)
**Handled platform-specific line-ending differences in Get-Content
-ReadLine - Tail tests
When the Pester tests were invoked over PSRP and the environment was
more pristine than a local client, the lack of a "foo" variable in some
scope caused the Pester test suite to emit an error at the end, failing
the PSRP build.
Removing the Clear-Variable directive eliminates this error, and is not
necessary for the Pester test itself.
The latest xUnit packages fix the "could not resolve coreclr path"
problem we were having. To resolve all dependencies, the cli-deps feed
was replaced with the aspnet feeds.
However, the latest xUnit packages do not allow us to set the default
AssemblyLoadContext.
- The Get-Process cmdlet on OS X has issues due to permissions
- The Get-Process test in NativeLinuxCommands should have been removed
- The ProcessName property has the same bug that has been fixed on Linux
JumpingYang001