- FullCLR build is disabled in this change.
- FullCLR build related functionalities in `build.psm1` and `AppVeyor.psm1` are disabled. They are not cleaned up from `build.psm1` and `AppVeyor.psm1` yet. We need to adopt .NET Core 2.0 to verify the portable module concept, and if that works well, we will remove the Windows PowerShell source code and clean up our scripts.
- `dnxcore50` and `portable-net5+win8` target framework monikers are removed.
- Dependency on `Microsoft.NETCore.Portable.Compatibility` is removed. It's not necessary, but it may come back when we work on supporting the `portable module`. Its necessity can be reviewed at that time.
- I didn't spend the time to try building powershell in Visual Studio 2017. We should have a separate issue for that. It's tracked by #3400
The `TypeCatalogParser` project is replaced by a MSBuild target to gather the dependency information.
Due to .NET Core SDK issue [#1021](https://github.com/dotnet/sdk/issues/1021), our meta-package project `Microsoft.PowerShell.SDK` starts to generate an empty assembly during the build and that results in an empty assembly `Microsoft.PowerShell.SDK.dll` appear in `publish` folder and in `.deps.json` file. We cannot simply remove the assembly because it's now part of the TPA, and removing it will cause powershell to crash at startup. We have to live with this empty assembly until that .NET Core SDK issue is fixed. It's tracked by #3401.
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 way it can also be deployed automatically, removing the last manual
copy steps from our build scripts.
Travis and AppVeyor configurations updated for new submodule location.
Same as ps1xml files: already deployed in the wild, i.e. not source
code. Allows to remove recursive copies from build scripts and rely just
on CLI's behavior.
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."
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.
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.
Deploying module is a bit funky until dotnet-cli gives us more control
over which libraries to build and where. Theoretically we'll be able to
package System.Management.Automation and depend on the package instead,
so Commands.Omi can be its own project entirely.
Cleaned up the Commands.Omi project.json as it had some unnecessary
cruft from where it was copied. Also removed the AssemblyInfo as it does
not matter for a new module.
Moved the Get-OmiInstance Pester test to the project's test folder so it
doesn't run with our suite of tests (as it takes a dependency on OMI).
Link to them instead so they don't get out of date. Explicitly fix the
incorrectly named file with an explicit link name. Also deploy the types
files with fixes to monad to fix shell output for various cmdlets.
Bumps monad submodule.