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.
Per dotnet/cli#1783, this should resolvePowerShell/PowerShell#638.
Unfortunately, per dotnet/cli#1839, the Ubuntu package feed is
out-of-date. So now Travis and AppVeyor aren't quite in sync. This is
not great, but the Ubuntu version of CLI does not have the same
regression that the Windows version had.
The readme has been updated to note how to install an actually
up-to-date copy on Linux.
Address Andy's comments about build script.
Add more information about the version into build
Use windows inbox version of pester for FullCLR
Revert dotnet cli to a known good version to avoid #638
This way it can also be deployed automatically, removing the last manual
copy steps from our build scripts.
Travis and AppVeyor configurations updated for new submodule location.
I originally used `deploy_script:` section for publishing artifacts.
This section is not invoked on Pull Requests.
Hence, use `on_finish` section instead, so we can consume artifacts from PRs as well.
This change brings a very minimal set of tests and make
build fail, if we cannot load some PS assamblies on FullCLR
We should increase test coverage for FullCLR in future.
