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.
Since we start include CRT runtime inside powershell.exe,
the size of executable jumped from 32kb to 1Mb in DEBUG.
Release produces about 20kb, so we keep size managable.
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.
The updated packages fix our Start/Stop process tests, which were
failing intermittently due to the process name appearing incorrect.
See dotnet/corefx#5421 for further details.
Proper deployment of the Modules we support allowed me to remove my
work-arounds using the deprecated SnapIn system to load all PowerShell
libraries via Modules.
I still don't like that this is done in build scripts, but we need
better asset support from .NET CLI to change how this is done.
PowerShell.Utility now deploys the CoreClr manifest, so unsupported
commands don't show up erroneously.
Latest versions of .NET CLI ignore --output and instead publish to a
long path inside of it. Until this is resolved properly, we can work
around it by copying to the expected location.
Revert this when CLI is fixed.
