Submodule adds unnessesary complexity.
This commit removes dependency on pre-generated C# bindings.
Start-PsBuild -ResGen will call Start-ResGen.
It also has auto-detect logic to simplify first time expirience.
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.
Specifically this enables us to leverage `dotnet-resgen` to
auto-generate the `resx` files into `resources` files for the default
culture, which are then compiled into the SMA assembly.
This requires a change to the C# bindings. The Windows build system
takes `file.resx` and compiles `file.resources`, but CLI prepends the
assembly name, thus compiling `SMA.file.resources`. So the resource
manager in the generated bindings must be adjusted to look for
`SMA.file` instead of `file`.
Note that C# bindings cannot yet be auto-generated.
Given localized resources of the form `file.en-US.resx`, `dotnet-resgen`
will create a satellite assembly and publish it to
`en-US/SMA.resources.dll`, so #666 will not be a technical problem.
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.
This allows us to remove the duplicated copying steps from our Windows
and Linux build scripts. These files are already distributed to users of
Windows, and so are not "source code."
To enable building on both Core and Full CLR with the same project.json
files, the superset of file dependencies for both builds must be
included. The set differences are applied by `CORECLR` preprocessor
guards around the files themselves.
The file name cases were corrected for case-sensitive filesystems.
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.
Dongbo Wang