az functionapp list runtimes does not return desired information for Windows

[mattchenderson]

Related command
az functionapp list-runtimes --os "windows" --query "[?runtime == 'dotnet-isolated']"

The specific parameters are an example. there to illustrate the point.

Is your feature request related to a problem? Please describe.
The output of the above command today is as follows:

[
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": ".4.8"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "8"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "7"
},
{
"runtime": "dotnet-isolated",
"supported_functions_versions": [
"4"
],
"version": "6"
}
]

This has a few issues. First, it does not describe required information. Contrast with the same command, but with "linux" instead of "windows". You will see linux_fx_version in the response, which can be used for configuring the app. However, other settings may be required in Windows, and for "dotnet-isolated" here, I'm primarily looking for the value of netFrameworkVersion. This will inform a later az functionapp config set. I happen to know the format of this (e.g., "v8.0"), but someone who did not might encounter an issue on the next step of a common operation.

Perhaps more critically, these are not surfacing end-of-support dates which are present in the backing Stacks API. The tool should provide users with this information so that they do not select a version that is nearing or out of support.

Tangentially, it's also weird that .NET Framework 4.8 comes back as ".4.8" with that extra leading '.' which is not present in the underlying Stacks API.

Describe the solution you'd like
I can see from the code that something has been attempted around this before:

azure-cli/src/azure-cli/azure/cli/command_modules/appservice/custom.py

Lines 3337 to 3344 in 8816586

	self.windows_config_mappings = {
	'node': 'WEBSITE_NODE_DEFAULT_VERSION',
	'python': 'python_version',
	'php': 'php_version',
	'aspnet': 'net_framework_version',
	'dotnet': 'net_framework_version',
	'dotnetcore': None
	}

Granted, those names have been normalized to be more python-ic rather than reflecting what they look like in the API or the CLI (also true of linux_fx_version). Regardless, none of the requisite values make it through. The code comment about getting support from the API is valid, but the information is definitely present in property bags which could simply be surfaced. See the following from the Stacks API: siteConfigPropertiesDictionary, appSettingsDictionary, endOfLifeDate

Describe alternatives you've considered
A user would otherwise need prior external knowledge of the properties and formats needed to configure the app properly for the stack should they be performing any upgrade operations. They would need to know the end of support dates from another source.

[yonzhan]

Thank you for opening this issue, we will look into it.