When specified, it will join the given path relative to the PowerShell
repository. This is useful to choose where the built artifacts will
end-up, which is necessary to fix VS Code tasks.
Instead of using `dotnet publish`, we can use `dotnet build` and the new
`netcoreapp1.0` framework with a new dependency on
`Microsoft.NETCore.App` to generate output that does not include the
runtime, but can be run anywhere (given the installation of the
runtime).
While we cannot yet adopt a dependency on the shared host until .NET
Core RTM, we are forced to switch to this system anyway because the
latest RC3 packages and CLI do not support `netstandardapp1.5`. See
dotnet/cli#2482.
Thus we're in an in-between state where we have to use `netcoreapp1.0`,
but cannot use `"Microsoft.NETCore.App": { "type": "platform" }` to
utilize the shared host, as we need to continue to ship our host.
Without specifying "platform", we retain the status quo with respect to
build steps and outputs.
Additionally, there is no longer a good reason to use the RC3 packages,
and it has been advised we switch to RC2 since the
`Microsoft.NETCore.App` is only available for RC2. We must update
packages because our current version can no longer be debugged.
Deduction of PowerShell output path is now done in `New-PSOptions`,
which returns a hash table representing the build options, so that it
can be done outside of `Start-PSBuild`.
`Start-PSBuild` saves the options it creates as a script-local variable,
`$script:Options`.
`Get-PSOutput` will either unwrap the an options hash table parameter,
the script local options hash table, or use the default options.
Thus, if `Start-PSBuild` hasn't been run, it can be used to get the
output path given non-default options like this:
```powershell
Get-PSOutput -Options (New-PSOptions -Publish)
```
Or simply call `Get-PSOutput` to get the best-guess default path.
Note that because ValidateSet does not support the use of constant
variables, the set of runtimes has to be duplicated, and an empty
runtime is supported.
Unfortunately, Travis CI's OS X machines are 10.9.5, per
https://docs.travis-ci.com/user/osx-ci-environment/#CI-environment-OS.
While NuGet supports the RID, .NET Core does not yet publish 10.9
packages, resulting in a build failure we can't do anything about.
I've asked for best-effort support by providing runtime packages for
10.9 in dotnet/corefx#7731.
Revert "Add OS X 10.9 runtime"
This reverts commit 19ab0de84c.
- Now checks that previous Start-PSBuild was with -Publish
- Uses $script:Output automatically
- Uses /opt/microsoft/powershell on Linux per FHS
- Uses /usr/local/microsoft/powershell on OS X per FHS
- Specifies "--rpm-os linux" for RPM packages built elsewhere
- Creates symlink on demand for packaging
- Puts symlink in /usr/(local)/bin as it is expected to be in PATH
- Uses $Arguments array for better syntax
- Resolves#800
Note that if the target of the powershell symlink exists, `fpm` aborts
with a `utime` error on OS X.
CMake will now output the artifacts of the native build into the
ConsoleHost project, where .NET CLI picks it up as content and deploys
it automatically.
This is a breaking change that requires developers to update their
version of .NET CLI. In order to stop specifying where dotnet should
output the artifacts, we need to be able to guess their location
correctly, which requires knowing the current RID (and framework).
This is a breaking that stops publishing PowerShell by default, and
instead relies on `dotnet build`. Thus the artifacts will be output to a
new (RID, framework, and project dependent) location.
Publishing will still be needed to produce packages, but this logic will
be moved into `Start-PSPackage`.
