Pin the .NET Core SDK

[AArnott]

This avoids the warnings in the build on machines with preview versions of .NET SDK installed.
It also ensures you can build this a long time from now when the SDK makes breaking changes because you'll always use the specified SDK.

As part of this, I added script for your CI agents to install the SDK and runtimes you require. These scripts work on local dev boxes too, and I added documentation to your contributors instructions explaining how to make sure the required SDK is installed.

I updated a few agents to run on VS 2019 machines instead of VS 2017 as well.

[bording]

Since we're talking about making more CI changes in #1760, does it make more sense to do that instead of merging this?

I have to say that I've not typically seen the benefit of pinning the SDK version, and don't do that in any other projects I'm involved with.

[AArnott]

Since we're talking about making more CI changes in #1760, does it make more sense to do that instead of merging this?

The work for #1760 builds on this one anyway, so it's not a big difference to me whether this PR is taken first.

I have to say that I've not typically seen the benefit of pinning the SDK version, and don't do that in any other projects I'm involved with.

As part of the #1760 work, I'm turning on TreatWarningsAsErrors=true in the build so that we stay build warning clean (and #1759 got us to be clean in the first place). Newer .NET SDKs introduce new warnings. For example, upgrading from 2.1.802 to 3.1.100 introduces a couple new build warnings that would fail the build. Unless you want your builds to just start failing on the schedule of your CI machines' updating their default SDK versions, you'll want to pin for reliable builds. Pinning puts you in control of when those warnings show up and your builds break.

That's just the warnings side. NuGet and other .targets in the SDK tend to evolve across SDK versions and sometimes in breaking ways -- and even more dangerously, sometimes very subtle ways you don't catch right away.
Again, pinning the SDK gives you control over when you update the SDK so that you can do it at a time when you can budget time for extra validation.

Finally, it gives piece of mind if you have to service older releases. In Visual Studio we have to service the product for up to 10 years. Going back and building software that is 9 years old is extremely hard if you haven't pinned the versions of all your dependencies. The ability to pin a .NET SDK is relatively new so we haven't done it for software 9 years ago, but I've done it for the past year or two and it's already been useful. There are several repos I own that I can't update the SDK version for because they break, so I have to find time in the future to work through the issues so I can keep moving forward with SDK versions. But I'm glad they're not broken in the meantime.

And the thing about "well, I'll just pin it if it ever breaks", is well, which version were you using when it last worked? There's no documentation for that. You just have to guess. Pinning it in advance keeps away the guess work and the fire drills.

[bording]

@AArnott Thanks for articulating the reasons why it makes sense to pin the SDK. That lines up with all the reasons I've heard for it before, and I agree it makes sense.

Despite that, I still personally find it distasteful, because I really don't like having a bunch of old SDKs and runtimes installed on my machine. I'd much rather just keep things up to date.

It does make sense to go ahead and merge this, let me take a quick second look at everything.