After spending countless of hours on getting to the core of a bug, I eventually boiled down a problem to the use of string.Compare
with StringComparison.InvariantCultureIgnoreCase
in .NET 5.
Consider the following two dotnetfiddles:
- .NET 4.7.2: https://dotnetfiddle.net/KdErSK
- .NET 5: https://dotnetfiddle.net/ZWfprp
When running the .NET 4.7.2 you get -1 as a result, when running .NET 5 you get 1 as a result.
After some browsing, this led to the following notice:
- https://learn.microsoft.com/en-us/dotnet/standard/base-types/string-comparison-net-5-plus
- https://learn.microsoft.com/en-us/dotnet/core/extensions/globalization-icu
So, going by this, a result of -1 is the NLS version, whereas the .NET 5 result of 1 is the ICU version.
However, when I spin up an Azure App Service in .NET 5 mode, the result of the above code in a Razor page is -1, AKA: the NLS version.
This can cause all kinds of weird issues, because two different systems lead to unexpected results.
When I add add the following to my project-file, as mentioned in the last article, my local environment also outputs a -1.
<ItemGroup>
<RuntimeHostConfigurationOption Include="System.Globalization.UseNls" Value="true" />
</ItemGroup>
No matter what kind of configuration I use in Azure, it will always keep outputting -1.
Long story, something is up on Azure. As per documentation, my Windows version is new enough to have ICU enabled. Looks like the Azure App Service is either using a forced NLS mode, or is running some ICU version my local machine doesn't have.
Anyone know how I can figure out which ICU version (if any) Azure is using, so I can use the suggestion from the documentation to use a AppLocalIcu? Otherwise, if something is clearly on the side of Azure, then my question is what the best location would be to report this?