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.
When an assembly that exists outside of the trusted platform assembly
list but in the GAC on Windows was loaded, the use of `Assembly.Load`
before the `LoadFromAssemblyPath` caused a recursive loop to occur.
This happens because an `Assembly.Load` on a not-yet-loaded
assembly is overridden, thus calling back into the
`AssemblyLoadContext.Load` override.
By attempting to load from the file path first, we avoid this loop.
However, loading TPA assemblies by their path throws an exception, so
now we catch this particular exception and attempt the load through
`Assembly.Load`.
This is safe for TPA assemblies since they're already loaded, thus the
`Assembly.Load` does not re-load the assembly, but simply returns it.
This should resolve#791.
Instead of checking if `Assembly.Load` returned null (it doesn't), check
if it threw `FileNotFoundException`, which it will if it doesn't find
the assembly.
The primary reason to do this is that the VS Code debugger is not
compatible with rc2.
Secondarily, we want to continue tracking CoreCLR/FX master branch,
which means to continue with the latest release candidates. Since we are
releasing in August, we will be able to pick up the converged RTM
version before release.
The only advantage of rc2 is that it is frozen; but we have this anyway
because we snap to particular builds.
All libraries now use the framework `netstandard1.5`, and import the
`dnxcore50` and `portable` frameworks. The app that is published,
Microsoft.PowerShell.Linux.Host, that is, the top-level dependency that
emits an executable, instead targets `netstandardapp1.5` and has a new
`runtimes` key so that .NET CLI's `restore` and `publish` commands know
which runtime implementations to resolve.
When switching to the new CLI, we needed to fix how we specified our
dependencies. In particular, the .NET CLI team helped me figure out how
to download packages that are reference assembly only on Linux, with
implementations on Windows. The result of this is the new `frameworks`
setup.
Additionally, we were incorrectly specifying our build dependencies;
that is, projects we also build (not packages). The solution was much
cleaner. We removed the `type: build` section and replaced it with the
version `1.0.0-*` that all our projects currently use.
The `project.json` files also had their names, descriptions,
indentation, and versions fixed.
The build scripts were simplified.
The packages are now dependencies of the `dnxcore50` framework itself,
rather than globally. The `compilationOptions` were pruned, with
`CORECLR` moved to frameworks, `_CORECLR` removed for all but
`Management.Infrastructure`, and `LINUX` moved to a new `Linux`
configuration, used only in `build.sh`. This configuration is
purposefully absent from libraries that do not use `LINUX`, so that it
is not relied upon without strong consideration. The dependencies
were pruned to reduce duplication.
