Instead of building PSReadLine from this repo, pull it from the gallery using nuget cache.
This pulls v2.0 of PSReadLine which does have documented breaking changes from v1.2, but the risk is small - the features that have changed are typically only used in a profile and aren't used all that often anyway.
Fix#996
Hardcodes version of modules pulled from PSGallery
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.
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.
Although there is a dedicated `coreclr-xunit` feed for this package, it
is missing some needed dependencies. Rather than add yet another feed
(`aspnetvnext`), we'll use the `cli-deps` feed as it has all the
packages that `dotnet-test-xunit` needs, and is likely to stick around.
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
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.
