Update BuildTools to 2.1.0-preview2-02621-01

[dagood]

Update dotnet/standard commit to bring in fixes for the new version (dotnet/standard#690), and fix init-tools.sh (same fix as standard).

Unblocks #371

[dagood]

Figured out the weirdness with tarball, I'm pretty sure. Repro steps from fresh dotnet/standard@2022919 standalone clone:

1. ./build.sh
2. rm -rf packages/microsoft.netcore.compilers/
3. ./build.sh

I do see microsoft.netcore.compilers.2.6.0-beta3-62316-02.nupkg in the repro tool VM's prebuilt/nuget-packages/ dir, but not in the root packages/ folder. I believe BuildTools handles the package not being there by building with the old Roslyn, which causes the failures like these:

/home/dagood/git/standard/Tools/Microsoft.CSharp.Core.targets(106,11): error MSB4064: The "OverrideToolHost" parameter is not supported by the "Csc" task. Verify the parameter exists on the task, and it is a settable public instance property. [/home/dagood/git/standard/netstandard/ref/netstandard.csproj]
/home/dagood/git/standard/Tools/Microsoft.CSharp.Core.targets(67,5): error MSB4063: The "Csc" task could not be initialized with its input parameters.  [/home/dagood/git/standard/netstandard/ref/netstandard.csproj]

It seems like nothing actually executes the restore command on this package in the tarball build (since init-tools doesn't run again in the tarball build?) so dotnet/standard can't find it.

[dagood]

I added a step to the tarball creation script that runs Tools/init-tools.sh to populate the packages/ dir with the package BuildTools now expects to be there.

Removed CoreCLR from known-good temporarily to see if this makes it past CI. This works on my machine with I limit the build to standard. (My docker install doesn't seem to be working, so I can't test the offline tarball build, but the online one seems to work.)

[dagood]

Green CI, but with CoreCLR taken out. Locally, I'm trying a merge of release/2.1 into @weshaggard's fix branch to see if that works. The merge is clean, BuildTools version is 2.1.0-preview2-02612-03 (dotnet/buildtools@5274e07) and CLI 2.1.2, which means it should be past at least the known break.

[dagood]

I'll add this to dependencies.props in my other PR (where I introduce dependencies.props) to match https://github.com/dotnet/coreclr/blob/2e5f43401b458315dc33c137f0ee0c5a02d810c2/init-tools.msbuild#L20-L22.

[dagood]

CI's green! Once dotnet/coreclr#17136 is in CoreCLR release/2.1 we can move off my fork.

[dagood]

@dseefeld @crummel PTAL

[weshaggard]

Note a huge deal but I generally perfer to not switch to forks but instead just use a branch in the main repo.

[weshaggard]

@dagood did you move coreclr to the tip of the release/2.1 branch + my fix? If so and that works then I can update the release/2.1 branch in coreclr to have the fix. It should be noted that my fix isn't enough and needs adjustments see (dotnet/coreclr#17226) to ensure other scenarios still work.

[dagood]

Yep, my commit is just your fix branch with release/2.1 tip merged into it. I'll push it to dev/dagood/source-build-fixes-preview2 in dotnet/coreclr to unblock for now, then we can switch back when you have the adjustments in.

[dseefeld]

Did you mean to leave this here?

[dagood]

Yeah, this makes the commands show up in the logs without the maintenance cost and risk of duplicating the commands in echo ... statements.

[dseefeld]

One comment. Otherwise, looks good.

[dagood]

The || exit $? pattern is what I came up with to make sure it exits on the first error. set -e would normally do this, but it doesn't apply when the command uses ||. (I used || on the subshell to notify the user that it failed rather than just having the script exit without any info.) Better ideas welcome.