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.
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.
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.
- Add badge to readme
- Use language 'cpp' because 'csharp' would bring in Mono
- Set to Trusty Tahr (Ubuntu 14.04)
- Only clone necessary submodules
- Use SSH for powershell-ci user access
- Install dotnet-cli
- Build PowerShell
- Run Pester tests
Instead of Microsoft.PowerShell.Linux.Host
Since this changes the name of the library,
System.Management.Automation's assembly info needed to be updated.
- Pester source code moved to `test/Pester`, deleted `ext-src`.
- Pester tests (.ps1 files) moved to `test/powershell`
- xUnit tests (.cs files) moved to `test/csharp`
- Third-party script test moved to `test/shebang`
- Removed more pre-processor conditionals
- Loads libpsl-native
- Pruned wmi (rewrote history)
The wmi folder was massive, and we did not need 99% of it, so a `git
filter-branch --tree-filter` was performed to remove all but the single
necessary subdirectory before pushing to GitHub.
The psl-monad repository can no longer be updated from the existing
GitSD sync. When the PSW teams have a Git repo for the monad codebase,
we will apply our patches to it and delete this fork.
The monad-native submodule no longer owns a native host whatsoever, with it moved to the provider, and the provider's build system refactored to use CMake.
Because CMake is way better, even for dealing with OMI.
The former is available, the latter is not. For our simple case of a
readline-esque shell on Linux, they seem equivalent. This removes the
import of libpsnative and the native calls to get terminal width/height.
PSRP will of course still require it, but now the managed host sets up
the assembly load context, meaning we can depend on the emitted binary
from dotnet-cli.
It is too messy to count on being able to stop the infinite processes
that Start-Process tests start. All processes will now stop on their
own, removing the dependency on Stop-Process. The wait test is now not
much of a test however.
