This reverts the `if !CORECLR ... #endif` guard surrounding FullCLR
files by applying the original diff from the `source-depot` branch, thus
the accidentally overwritten BOMs were restored as well.
- Get rid of the assumption that all framework assemlbies live in
the same place
- Enable build scenario (assemlbies are referenced directly from unpacked
nuget packages)
- Fix#766
- Re-enable Add-Type tests
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.
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.
Commands.Utility now needs Microsoft.CodeAnalysis.CSharp, which doesn't
explicitly target `dnxcore50`, so now Commands.Utility and the packages
which depend on it now much `import` the Portable Windows framework.
This also required adding the aspnetvnext feed.
System.Management.Automation now requires System.Diagnostics.StackTrace.
Removed CorePsPlatform.cs from the build mapping so that I could perform
it before merging.
Note that SMA by default now builds with a bunch of tracing files for
ETW, which cannot be compiled on Linux and must be hand-removed from the
windows-build auto-generated compileFiles output.
Removes dependency on Microsoft.Extensions.Platform.Abstractions.
Makes use of native executable from `dotnet-cli` impossible; must use
`powershell` from monad-native.
Andrew Schwartzmeyer