Use global.json file to centralize SDK version

[jmaeagle99]

There are several places in build pipelines that specify the SDK version and there is no clear documentation as to which version of the SDK should be used to build the .NET projects.

Proposed Solution

Add a global.json file to the repository that specifies the version of the .NET SDK to use. This has the benefit of:

• Removing the need for build pipelines to know which version of the .NET SDK is necessary.
• Having a central location that allow .NET tooling understands how to determine which version of the .NET SDK to use.
• Allow Dependabot to potentially update the .NET SDK version if using the full triplet version.

[cretz]

Also, if possible to include this anywhere other than the top-level, that'd be ideal. We already have too many top-level files for my liking (I would have liked not to have omnisharp.json there but I was disagreed with). It continues to move the README below the fold and make for a bit of an uglier view when arriving at the repo.

[jmaeagle99]

Also, if possible to include this anywhere other than the top-level, that'd be ideal.

There are two classes of implicit references to the global.json that I see that would be used in this repository:

• The setup-dotnet GitHub action
• The solution and project files

The GitHub action allows specifying a path to global.json file, so it can be located anywhere in the repository for these.

For the solution and project files, the global.json has to be at some common root of all of those. At this time, that would be the root of the repository. However, if the tests directory was moved under the src directory, then the global.json file (and likely all of the other .NET files like the editor config, omnisharp, props, etc) could be put under that directory; these are typically looked up recursively from the directory of the solution/project file up to the root of the filesystem.

I'm not certain that's justification enough to shuffle around the source code in the repo though. The number of files that are currently at the root of the repository is not very large and feels less than a typical .NET repository.

[cretz]

Yeah, we don't want to move around the entire source. But we've been operating without this file fine too, so one wonders if it is that required. I do recognize we have fewer top-level files than a typical .NET repo which is very much on purpose.

[jmaeagle99]

User Experience
If a person works consistently in the code base, said person probably already knows the requirements for building this repository. As someone newer to this project, I had to search to determine what version of the .NET SDK was necessary before the move to the .NET 10 SDK. Using a global.json file makes it clear as to what version is necessary and provides a user experience when that requirement is not met:

Requested SDK version: 10.0.100
global.json file: <path>/temporalio-sdk-dotnet/global.json

Installed SDKs:
8.0.416 [/usr/local/share/dotnet/sdk]

Install the [10.0.100] .NET SDK or update [<path>/temporalio-sdk-dotnet/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

Version Consistency
Each aspect of the build process doesn't need to understand what is the .NET SDK version that is necessary to use to successfully build the repository. Currently, there are 5 separate actions/setup-dotnet@v4 task invocations in 4 GitHub workflows that all need to agree on what is the correct version. Using a global.json file, specifying that version should not be necessary.

All of the "native" .NET tooling understands global.json and how to look it up.

Maintenance
Next time that .NET SDK needs a new major version bump, there will be fewer files and occurances that would need to be updated. After this type of change, I count two places: the global.json file and the container image specification of the Alpine images.

Pinning
In the unlikely event that a new SDK patch breaks the ability to build, using a centralized version allows the repository to be pinned to a specific version to avoid build breaks.

Dependabot
While not used currently, dependabot understands the global.json file and can update the SDK version as necessary to make sure that it is not set to a vulnerable version.

[cretz]

Yeah, I think it's understood why a global.json file has value for contributors and CI, just trying to reduce top-level files for everyone that views this repo (which is a lot more than contributors). Having said that, it's not that big of a deal if you think it's important enough.