With the latest packages, a lot more System.Console API is available.
This commit implements what is now available through the API.
Where an API functions correctly on Linux, the result of a call through
PowerShell works as expected. Where it is not, a nice
`PlatformNotSupported` exception is thrown (and displayed by
PowerShell).
On Linux:
- `$host.ui.RawUI.WindowTitle` can be set but cannot be get
- `$host.ui.RawUI.CusorPosition` can be set and get
- `$host.ui.RawUI.CursorSize` can be get but cannot be set
- `$host.ui.RawUI.MaxPhysicalWindowSize` can be get
- `$host.ui.RawUI.MaxWindowSize` can be get
- `$host.ui.RawUI.WindowPosition` can be get but cannot be set
- `$host.ui.RawUI.WindowSize` can be get but cannot be set
- `$host.ui.RawUI.ReadKey` can be be used, but is only approximate
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 was a temporary work-around that now needs to be removed (mostly
because the xUnit tests are out-of-date because we didn't have a runner,
and it's not worth it to fix them). Rather than let more cruft
accumulate, we need to remove it.
Resolves#551
It is odd, but they're unsupported here. If a version is given, it
causes every build/publish to think it needs to be restored again,
because the lock file doesn't end up with a version.
Add almost all files to Microsoft.PowerShell.Commands.Management
One of them is Computer.cs that was listed in known issues.
We start to use a nuget packages generated for assemlbies that
cannot be listed in framework assemlbies, but exist in a GAC
on all windows machine and not a PowerShell assemblies
The first one is Microsoft.WSMan.Management
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."
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.
So short of re-implementing an entire new PSHost for non-interactive
sessions, this is a work-around. If a script (file or command) is passed
to the shell, we tunnel that information through to the raw UI so it can
skip calling out to the TTY (which may not exist).
There has to be a better way to do this, but the structure of PSHost >
UI > Raw UI just makes this incredibly difficult.
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.
This test was not viable as it didn't retain the process object,
instead relying on Get-Process with the process name, which could fail
to get the correct process (since no PID was available).
Since it is pointless to test Start-Process without -PassThru, and that
test was the exact same code as the fixed first test, it was removed.
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).
