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.
This resolves#817.
A PowerShell instance is created to load and execute profile code.
However, if the profile has a parse error, the instance never gets
created, thus we have to check that it's not null before disposing it.
The dotnet-core and aspnetcidev feeds provide all our required packages.
The aspnetvnext causes `dotnet restore` to take an inordinate amount of
time, which terminates our CI builds.
Reducing the number of feeds brings restore time from scratch down to 3
seconds on my machine.
The aspnetvnext feed was originally added for the CoreCLR xUnit runner
packages; but is no longer necessary.
Resolves#896.
When the Pester tests were invoked over PSRP and the environment was
more pristine than a local client, the lack of a "foo" variable in some
scope caused the Pester test suite to emit an error at the end, failing
the PSRP build.
Removing the Clear-Variable directive eliminates this error, and is not
necessary for the Pester test itself.
The latest xUnit packages fix the "could not resolve coreclr path"
problem we were having. To resolve all dependencies, the cli-deps feed
was replaced with the aspnet feeds.
However, the latest xUnit packages do not allow us to set the default
AssemblyLoadContext.
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.
Copy the Travis CI badge for 10.11. It is the same badge, but it will
fail if the build fails. I don't see a way to have separate badges, but
this highlights that the platform is being tested.
- The Get-Process cmdlet on OS X has issues due to permissions
- The Get-Process test in NativeLinuxCommands should have been removed
- The ProcessName property has the same bug that has been fixed on Linux
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 19ab0de84cec37bb90443df14d4e69f10c41e1b1.
When an assembly that exists outside of the trusted platform assembly
list but in the GAC on Windows was loaded, the use of `Assembly.Load`
before the `LoadFromAssemblyPath` caused a recursive loop to occur.
This happens because an `Assembly.Load` on a not-yet-loaded
assembly is overridden, thus calling back into the
`AssemblyLoadContext.Load` override.
By attempting to load from the file path first, we avoid this loop.
However, loading TPA assemblies by their path throws an exception, so
now we catch this particular exception and attempt the load through
`Assembly.Load`.
This is safe for TPA assemblies since they're already loaded, thus the
`Assembly.Load` does not re-load the assembly, but simply returns it.
- 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.
This action is completely valid on both Windows and Linux (and OS X)
operating systems; tested with `mklink` and `ln -s` respectively.
Note that targets for hard links must exist, thus we check specifically
for symbolic links.
Both the path globber in session state and the `New-Item` implementation
needed to be fixed to allow the target not to exist.
Resolves#801.
Also enable symbolic link tests on Windows.
While Windows will automatically open a URL used as a process by
launching a browser, OS X needs to use `open <URL>`, and Linux needs to
use `xdg-open <URL>` (the most distribution-independent way).
Resolves#802.
This should resolve#791.
Instead of checking if `Assembly.Load` returned null (it doesn't), check
if it threw `FileNotFoundException`, which it will if it doesn't find
the assembly.
The aliases which conflict with Linux native commands were consolidated
and removed with the pre-processor definition `LINUX`. Additionally,
several "conflicts" are purposefully kept and likewise consolidated.
They are kept because Bash itself stomps on the native commands with its
own built-ins, and so we're adopting the same behavior.
The `clear` and `more` aliases are edge cases where the functions they
call are already fixed for Linux, and so we keep these too.
Resolves#567.
