* Fix code PATs
* Fix feed PATs
* remove gallery commit
* update feed url
* Update to new variable groups
* Fix Variable name
* Fix credential template
* Disable Signing setup in prep stage
* Capture nuget source list
* lock down the firewall
* Add creds to feed switch to allow single switch location
* Use switch from build.psm1
* Use switch template instead of commands
* update to test feed
* disable codeql in jobs where we don't compile
* disable code sign validation for prep
* move capture steps to restore phase to see if it speeds things up
* remove duplicate capture of nuget config
* update test service
* Only build windows test service on windows
* warn when no config is generated
* try to fix test service
* fix web listener refs
* try removing dotnet tool
* update feedname with user info
* update package version that is not found
* try moving failing jobs to restore phase
* allow nuget inset in either phase
* update package ref
* use the right reporoot
* Move everything to restore
* Try adding build phase
* put nuget files in the right place
* move bootstrap into yaml
* remove onebranch agent items from macos build
* switch to environment variable
* bump a couple of packages
* fix formatting
* Fix static analysis issue
* update feed url to test restoring everything
* install the AzFeed cred provider
* fix binlog issues
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.
Travis Plunk