Making dotnet sdk check distro-aware

[mateusrodrigues]

Motivated by dotnet/sdk#47639, I dug through the dotnet sdk check command source-code to better understand how distro maintainers could be able to customize its output based on .NET versions available in their own distros. Here's what I found.

The sdk check tool relies on a JSON document published online to sort through available .NET versions and figure out whether the .NET versions installed in the system are up-to-date, end-of-life, and whether new feature bands are available. The tool defaults to the JSON document published in builds.dotnet.microsoft.com.

However, it is possible to override the location of the JSON manifest by creating a file called sdk-check-config.json under {DOTNET_ROOT}/sdk/{SDK_VERSION} with the following structure:

{
   "ReleasesUri": "{your_json_uri}"
}

or

{
   "ReleasesFilePath": "{your_local_json_doc_path}"
}

Therefore, it seems to be sufficient for distro maintainers to ship said file within the dotnet-sdk-* package and have it point to their own version of the releases JSON document.

Note: It's still unclear to me how much of the file the tool really needs, i.e. if we can ship a smaller version of releases-index.json for the purpose of the tool only.

I made a small PoC on my machine by downloading the releases-index.json file, making some changes with regards to feature bands available, and was successfully able to make my dotnet sdk check run stop advertising the 2xx .NET 9 feature band 😄

With that said, it seems quite possible to have some sort of automated tool dig through a distro's published packages within their own archives and build the corresponding JSON representation for sdk check to consume.

One last detail

The tool prints the following message in the footer:

The latest versions of .NET can be installed from https://aka.ms/dotnet-core-download. For more information about .NET lifecycles, see https://aka.ms/dotnet-core-support.

It would be quite nice if that one could also be customized. Currently, these strings sit within resource files, so it doesn't seem to be possible to override them at runtime.

cc @dotnet/distro-maintainers

[MichaelSimons]

Therefore, it seems to be sufficient for distro maintainers to ship said file within the dotnet-sdk-* package and have it point to their own version of the releases JSON document.

It doesn't seem right to bundle this as static information into the sdk package. This data should always reflect what the most recent release is so that when running an older version, it will inform the user that the currently installed version is out of date. A better approach would be for distro maintainers to publish their own version of the release.json to a known location that their source built SDKs reference. Alternatively, perhaps the consuming SDK logic can be modified to pull this information directly from the package manager dynamically rather than reading the release json file. In other words it would be ideal if there is a shared model the core logic operates on. For Microsoft, the model is populated from their releases json while for distro maintainers, it is populated from the package feed.

It would be quite nice if that one could also be customized. Currently, these strings sit within resource files, so it doesn't seem to be possible to override them at runtime.

I think this is a good opportunity to work with the SDK folks (@baronfel and @marcpopMSFT) to get the right extension mechanisms in place if they don't already exist for you to be able to control this behavior. Obviously you can have a customized resx file for yourselves but it would be nice to have a stronger "contract" to avoid breaks (e.g. upstream changes the resx name).

[mateusrodrigues]

It doesn't seem right to bundle this as static information into the sdk package. This data should always reflect what the most recent release is so that when running an older version, it will inform the user that the currently installed version is out of date.

The file we're bundling is not the actual releases-index.json file, but the sdk-check-config.json file, which would contain a URL pointing to the distro's own releases-index.json. This overriding mechanism already exists. Sorry, perhaps I wasn't too clear on the intent here 😅

[MichaelSimons]

Thanks for the clarification. That makes sense. My point still stands on the possibility of an extension point for the resource strings.