* rel/1.1.0: (41 commits)
Updating the Sdk to one that includes the error surfacing work.
Update NuGet to 4.3.0-preview2-4082
Update NuGet to 4.3.0-preview1-4081 and SDK to corresponding 1.1.0 based version
Updating MSBuild to 15.3.0-preview-000246-05 to match VS.
Updating the global.json creation to use the IFile interface and adding a unit test to cover it.
Making restore use a config file so that it does not use fallback folders that may exist in the machine.
Dropping a global.json when running the first run experience with a version that matches the version of the CLI being used in the command that triggered the first run.
Updating the websdk version for 1.0
Trying to fix the opensuse42 test failure, where we tried to invoke a tool that target 1.0.4 where the 1.0 runtime is not available.
Pinning the stage0 to the last build out of rel/1.0.1 and adding a project to download 1.0 dependencies for test assets.
Updating the branding to rel/1.1.0
Dummy commit.
Adding the access token to the lzma url.
Dummy change to force a build.
Reverting the msbuild version to the release version.
Adding the web feed to nuget.config, as some packages failed to mirror and we need a build ASAP.
Updating the msbuild, SDK and Web SDK versions.
Dummy commit to kick off the build.
the FSharp.NET.Sdk version `-bundled` contains only the Sdk dir
bump f# sdk package version
...
New file name structure for the runtime and the CLI
per: https://github.com/dotnet/designs/issues/2
The renaming of assets, therefore the dotnet installation scripts must change to accommodate.
Trivial:
"Write-Host" should be "Write-Output"
Our build scripts were pulling down all of buildtools and run.exe in
service of "clean.{cmd|sh}". While having consisent commands across
the repos is a good thing to strive for, we are pulling down a bunch
of additional stuff we don't need for simple commands that have well
known analogs (e.g. git clean).
If we had been all in on run.exe, this might have made sense, but we
aren't, so it feels like something we should clean up.
By doing this, we can stop downloading bootstrap from github when we
build (super dangerous anyway because changes in buildtools could have
broken us).
In addition, I changed the way we install dotnet to just invoke the
script in `scripts/obtain/` instead of downloading a version from
GitHub. This makes local development of changes to obtain easier and
removes yet another place we had to download a script.
* Add support to build with the linux portable
* Pass targets to run for the linux portable
* Address PR comments
* Update the bootstrapper version
* Address the PR comments for improving the help text
* Fixing permissions
* Allow host info passed in from the command line to override machine settings
* Simplify the logic
* Address PR comments to keep a separate HostRid and HostOSName that are static
* Rename to BuildInfo.props
* Address PR comments
* Fix the previous merge
* Fix spacing
* Address PR comments
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.
* Switch to using new bootstrap script to initialize buildtools.
* Set up the version-specific shared runtime symlink in run-build so buildtools doesn't have to care about it.
* Address code review feedback.
* Addressed code review feedback.
* Change to using bootstrap script for Linux build as well.
* Change to using latest for CLI.
