The powershell project's `Main` function initializes the custom
`AssemblyLoadContext` and then delegates to `UnmanagedPSEntry.Start`.
This lets us undo several changes to the `ConsoleHost` managed
entry (notably, the `Start` function signature does not have to change,
thus the `consoleFilePath` variable still exists).
The `src/powershell` project builds Core PowerShell as a .NET CLI app,
with a dependency on `Microsoft.PowerShell.ConsoleHost`, so that the
latter can remain a library.
When Open PowerShell is built (as .NET Core project), `OPEN` is defined.
The `Start` function normally used as the entry point from PowerShell's
custom native host is instead the real `Main` entry point of the
program, so it can be launched from the `dotnet` host.
Because Core PowerShell depends on the native host to setup the custom
assembly load context, we do it here in managed code immediately on
start-up.
CMake will now output the artifacts of the native build into the
ConsoleHost project, where .NET CLI picks it up as content and deploys
it automatically.
So that the resource manager doesn't try to load a non-existent
satellite assembly (and thus throw).
The culture `en-US` is the default `CurrentCulture` on all platforms I
tested, specifically not `en`.
Note that there is a problem with the FullCLR build where some other
assembly is still attempting to reference `Logging.resources` instead of
`System.Management.Automation.Logging.resources`.
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.
James Truher