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.
- Get rid of the assumption that all framework assemlbies live in
the same place
- Enable build scenario (assemlbies are referenced directly from unpacked
nuget packages)
- Fix#766
- Re-enable Add-Type tests
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.
