* remove reference to TestAssetsManager in dotnet-add-reference
* remove TestAssetsManager dependency from dotnet-build
* remove TAM ref from dotnet-list-reference
* remove TAM dependency from dotnet-msbuild
* remove TAM dependency from ProjectJsonMigration tests
* remove TAM dependency from dotnet.Tests
* remove TAM dependency from dotnet-new.Tests
* remove TAM from dotnet-pack.Tests
* remove TAM from dotnet-publish.Tests
* remove TAM from dotnet-restore.Tests
* remove TAM dependency from dotnet-remove-reference.Tests
* remove TAM dependency from dotnet-run.Tests
* remove TAM dependency from dotnet-test.Tests
* remove TAM dependency from Microsoft.DotNet.Cli.Utils.Tests
* remove TAM from TestBase
* remove TAM
* remove newly introduced dependency on TAM
The build agents in our VSTS pool don't yet have MSBuild 15, so the
signing project can't import any MSBuild 15 projects. (The signing
project is built with the desktop MSBuild because MicroBuild depends on
it.) Once the agents have MSBuild 15, this import can be added back.
- Fix build issues due to .props file not existing on a clean
enlistment
- Fix path separator issues on *NIX
- Add update-dependencies.sh
- Support -Update in update-dependencies.ps1
* First try at refactor of Prepare.targets
* Enable restore of CLI build tasks
* Fix up build
* Feedback
* Newlines
* Add new props to sln
* CommitCount
* NuGet.config
* WorkingDir
* packages dir path
* Add missing nuget.configs
* Workaround for https://github.com/NuGet/Home/issues/4583
* Match NuGet.Config casing
* Put back Version Badge Properties
* Remove duplicate
During the cli build, the cli downloads and executes the bootstrap
script from buildtools. The bootstrap script then downloads and executes
the dotnet-install script from cli, but in the 'rel/1.0.0' branch, not
the master branch.
This means that someone building cli's master branch will end up using
the dotnet-install.sh or dotnet-install.ps1 script from cli's rel/1.0.0
branch.
Fix that by telling the bootstrap script to download and use the version
of dotnet-install script from the master branch (which is the current
branch the user is building).
Ideally, we would just call the dotnet-install script in the current
repo/branch, but because the bootstrap script sits in the middle and is
part of a different repository, we can't.
This is a workaround for #5410.
- Take the latest VersionTools, so we can take advantage of new features.
- Update what files need to be updated - DependencyVersions.props.
- Clean up the powershell script.
