webapp list-runtimes values cannot be passed directly to webapp create on Windows

[btardif]

Describe the bug

az webapp list-runtimes returns pipe-delimited .NET runtime config values, while az webapp create --runtime documents and accepts colon-delimited Framework:Version values. Following the webapp create instruction to use list-runtimes produces values that cannot be passed directly to the create command. On the standard Windows MSI installation, the pipe is additionally reinterpreted by the az.cmd launcher.

Related command

az webapp list-runtimes `
  --os-type windows `
  --runtime dotnet `
  --query "[?contains(version, '10.0')].{os:os,config:config,version:version}"

az webapp list-runtimes `
  --os-type linux `
  --runtime dotnet `
  --query "[?contains(version, '10.0')].{os:os,config:config,version:version}"

az webapp create ... --runtime 'dotnet|10'

Errors

The Windows create command fails with:

'10' is not recognized as an internal or external command,
operable program or batch file.

Issue script & Debug output

Runtime catalog output:

[
  {
    "config": "dotnet|10",
    "os": "Windows",
    "version": "10.0 (LTS)"
  }
]

[
  {
    "config": "DOTNETCORE|10.0",
    "os": "Linux",
    "version": "10.0 (LTS)"
  }
]

az webapp create --help says:

--runtime: Canonicalized web runtime in the format of Framework:Version,
           e.g. "PYTHON:3.14". Use `az webapp list-runtimes` for available list.

The Windows MSI launcher is C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin\az.cmd and forwards arguments through %*; cmd.exe treats | as a pipeline operator.

Expected behavior

az webapp list-runtimes should expose a value that can be passed directly to az webapp create --runtime, or return separate clearly named fields for:

• create-command syntax (Framework:Version), and
• site-configuration syntax (Framework|Version).

The instruction to use list-runtimes should not lead to a failing command on the standard Windows MSI installation.

Environment Summary

azure-cli                         2.88.0
core                              2.88.0
telemetry                          1.1.0

Extensions:
azure-devops                       1.0.6
kusto                              0.5.0
resource-graph                     2.1.1

Dependencies:
msal                              1.36.0
azure-mgmt-resource               24.0.0

Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Python (Windows) 3.14.5 [MSC v.1944 64 bit (AMD64)]
PowerShell 7.6.4
Windows 10.0.26200

Additional context

These colon-delimited values work:

az webapp create ... --runtime 'dotnet:10'        # Windows
az webapp create ... --runtime 'DOTNETCORE:10.0' # Linux

No existing issue containing either exact .NET 10 catalog token was found in Azure/azure-cli.

Suggested assignee: @seligj95

[yonzhan]

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

[azure-client-tools-agent]

Bug Analysis

az webapp list-runtimes returns the runtime config field in the site-configuration format used by WEBSITE_NODE_DEFAULT_VERSION/linuxFxVersion style tokens:

• Windows: pipe-delimited, e.g. dotnet|10
• Linux: pipe-delimited, e.g. DOTNETCORE|10.0

But az webapp create --runtime expects (and its --help documents) the canonicalized Framework:Version colon-delimited syntax, e.g. dotnet:10 / DOTNETCORE:10.0.

Following the documented workflow of using list-runtimes output directly in create --runtime therefore fails. On Windows, the failure is compounded because az.cmd forwards arguments through cmd.exe, which reinterprets the unquoted | as a pipe operator, causing a shell parsing error ('10' is not recognized...) rather than a clean CLI error.

Location: src/azure-cli/azure/cli/command_modules/appservice/ — the list-runtimes command and the --runtime parsing/validation logic in custom.py (e.g. list_runtimes and the runtime parsing helpers used by create_webapp/update_webapp).

Suggested fix:

• Update list-runtimes to also emit (or default to) the colon-delimited Framework:Version token that --runtime accepts, e.g. add a runtime or canonical field alongside/instead of the raw config field, OR
• Make the --runtime parser in create/update accept both | and : delimited forms so a list-runtimes config value can be passed directly without transformation.
• Update the list-runtimes and --runtime help text to clearly state which field/format to use for create/update.

Reproduction:

az webapp list-runtimes --os-type windows --runtime dotnet --query "[?contains(version, '10.0')].{os:os,config:config,version:version}"
# -> config: "dotnet|10"
az webapp create ... --runtime 'dotnet|10'   # fails, especially on Windows MSI (az.cmd + cmd.exe pipe reinterpretation)
az webapp create ... --runtime 'dotnet:10'   # works

Use this EXACT PR title: [AppService] Fix #33822: az webapp create --runtime: accept list-runtimes config values

PR title & description format (required)

This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.

Use this EXACT PR title (copy verbatim, do not reword):

[AppService] Fix #33822: `az webapp create --runtime`: accept list-runtimes config values

Keep the backticks around the command and the Fix #33822: prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the [AppService] prefix, issue link, and backticked command must stay.

Description — follow the PR template and fill in:

• Link the issue — start the Description with a closing keyword so the PR auto-links and closes it: Fixes #33822.
• Related command — the az ... command this affects.
• Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
• Testing Guide — example command(s) showing the fix works.
• History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g. [AppService] `az <command>`: <note>.
• Keep the template checklist and tick the items you've satisfied.

---

Posted by agent-assist (autonomous bug-fix pipeline).