Summary
Please help investigate a reported .NET globalization/localization failure on Azure Linux 3.0 under WSL2 when a downstream CLI invokes its authentication dependency.
AzureAuth is the suspected failing component, not yet confirmed. Installation completes successfully; the exception occurs when subsequently running an authentication-dependent command. We have not yet isolated a direct azureauth reproduction or captured the failing subprocess.
Installing the .NET 10 SDK reportedly makes the downstream command work:
sudo tdnf install dotnet-sdk-10.0
This does not establish that AzureAuth requires .NET 10. Installing the SDK may also supply native dependencies. A self-contained .NET deployment can still depend on OS-provided libraries.
Reported environment and sequence
- OS: Azure Linux 3.0 (successor to CBL-Mariner), running under WSL2.
- AzureAuth version, distribution artifact, architecture, and resolved executable path: not yet captured.
- Start from a fresh Azure Linux 3.0 WSL2 environment.
- Install the downstream CLI; installation succeeds.
- Run its authentication-dependent command.
- A .NET exception described as being "related to localization" occurs.
- Install
dotnet-sdk-10.0 with tdnf, then retry; the command reportedly succeeds.
These are reported observations, not an independently reproduced minimal test. The downstream launcher can select an existing authentication executable, so identifying the exact executable is important.
Error details currently missing
The report does not include the verbatim exception, stack trace, AzureAuth command line/version, or relevant stderr. We cannot yet attribute it specifically to missing ICU, a particular .NET version, or AzureAuth itself. Globalization-invariant mode has not been validated as a safe or appropriate fix.
Expected behavior
If Azure Linux 3.0 is supported, the self-contained AzureAuth distribution should work with clearly documented native prerequisites, without requiring installation of a full .NET SDK as an unexplained workaround. If this distribution/environment is unsupported, please clarify that and the supported path.
Questions / next diagnostic steps
- Is there a known globalization/native-library dependency issue for AzureAuth on Azure Linux 3.0, and an existing fix or release to test?
- What native prerequisites are required for the supported Linux artifact?
- On a clean SDK-free image, capture the actual AzureAuth path/version and exact exception/stderr, then reproduce directly with the same supported authentication flow.
- Compare native packages before and after the SDK workaround to identify the dependency that changes the outcome.
- Validate any proposed fix or prerequisite guidance on a fresh image without the full SDK workaround.
Please keep logs free of access tokens, account identifiers, and sensitive resource URLs.
Related issue
#436 tracks Azure Linux packaging/documentation support and includes a later browser-launch/token-cache failure. This report is specifically about the post-install globalization/localization symptom; we do not yet have evidence that the failures share a root cause. Please consolidate if investigation establishes that they do.
Summary
Please help investigate a reported .NET globalization/localization failure on Azure Linux 3.0 under WSL2 when a downstream CLI invokes its authentication dependency.
AzureAuth is the suspected failing component, not yet confirmed. Installation completes successfully; the exception occurs when subsequently running an authentication-dependent command. We have not yet isolated a direct
azureauthreproduction or captured the failing subprocess.Installing the .NET 10 SDK reportedly makes the downstream command work:
This does not establish that AzureAuth requires .NET 10. Installing the SDK may also supply native dependencies. A self-contained .NET deployment can still depend on OS-provided libraries.
Reported environment and sequence
dotnet-sdk-10.0withtdnf, then retry; the command reportedly succeeds.These are reported observations, not an independently reproduced minimal test. The downstream launcher can select an existing authentication executable, so identifying the exact executable is important.
Error details currently missing
The report does not include the verbatim exception, stack trace, AzureAuth command line/version, or relevant stderr. We cannot yet attribute it specifically to missing ICU, a particular .NET version, or AzureAuth itself. Globalization-invariant mode has not been validated as a safe or appropriate fix.
Expected behavior
If Azure Linux 3.0 is supported, the self-contained AzureAuth distribution should work with clearly documented native prerequisites, without requiring installation of a full .NET SDK as an unexplained workaround. If this distribution/environment is unsupported, please clarify that and the supported path.
Questions / next diagnostic steps
Please keep logs free of access tokens, account identifiers, and sensitive resource URLs.
Related issue
#436 tracks Azure Linux packaging/documentation support and includes a later browser-launch/token-cache failure. This report is specifically about the post-install globalization/localization symptom; we do not yet have evidence that the failures share a root cause. Please consolidate if investigation establishes that they do.