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.
This resolves#817.
A PowerShell instance is created to load and execute profile code.
However, if the profile has a parse error, the instance never gets
created, thus we have to check that it's not null before disposing it.
The dotnet-core and aspnetcidev feeds provide all our required packages.
The aspnetvnext causes `dotnet restore` to take an inordinate amount of
time, which terminates our CI builds.
Reducing the number of feeds brings restore time from scratch down to 3
seconds on my machine.
The aspnetvnext feed was originally added for the CoreCLR xUnit runner
packages; but is no longer necessary.
Resolves#896.
**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
