Restrict Cultures Creation and full support casing in Globalization Invariant Mode

[tarekgh]

Restrict Cultures Creation in Globalization Invariant Mode

• Globalization Invariant Mode has been supported in .NET and .NET Core which used in the app scenarios that don't need any globalization support. This mode is turned on by default on some Docker container like Alpine containers.
  The behavior of the Globalization Invariant Mode used to allow any culture gets created if the culture name conform to BCP-47. When creating any culture (e.g. en-US), the Invariant Culture data will be used instead of the real culture data. This breaking change is changing this behavior which will throw exception when creating any culture other than Invariant Culture.

• Globalization Invariant Mode was supporting case mapping for ASCII characters range only. We are enabling full case mapping support for Globalization Invariant Mode.

Version introduced

.NET 6.0

Old behavior

• When Globalization Invariant Mode is turned on and the app creating a culture different than Invariant Culture, this creation operation succeeds but the returned culture will always use the Invariant Culture data at that time instead of the real culture data.
• When doing any operations need character case mapping (e.g. string comparisons, string search, and upper casing or lower casing string), the case mapping was done only for ASCII characters.

New behavior

• When Globalization Invariant Mode is turned on and the app creating a culture different than Invariant Culture, the culture creation operation will throw an exception. The new behavior will allow creating Invariant culture only.
• When doing any operations need character case mapping (e.g. string comparisons, string search, and upper casing or lower casing string), the case mapping will support all Unicode defined characters.

Reason for change

• The reason of this change is to have easier way to diagnose the problems when the Globalization Invariant Mode is enabled. Many users run their applications in environment that enable the Globalization Invariant Mode while they are not aware about that. The applications experience the Globalization Invariant Mode behavior which can be unexpected and will be hard to the app owners to know what is wrong and how to diagnose the problem.
• Support full case mapping is to have a better experience in Globalization Invariant Mode and make it more usable.

Recommended action

For anyone using the Globalization Invariant Mode and want to get back the old behavior, can do that by setting the configuration switch System.Globalization.PredefinedCulturesOnly to false in the application configuration file or define the environment variable DOTNET_SYSTEM_GLOBALIZATION_PREDEFINED_CULTURES_ONLY=false.

Category

• ASP.NET Core
• C#
• Code analysis
• Core .NET libraries
• Cryptography
• Data
• Debugger
• Deployment
• Globalization
• Interop
• JIT
• LINQ
• Managed Extensibility Framework (MEF)
• MSBuild
• Networking
• Printing
• SDK
• Security
• Serialization
• Visual Basic
• Windows Forms
• Windows Presentation Foundation (WPF)
• XML, XSLT

Affected APIs

• CultureInfo constructors
• CultureInfo.GetCultureInfo
• RegionInfo constructors
• String comparisons and search APIs
• String upper casing and lower casing APIs.

Issue metadata

• Issue type: breaking-change

[tarekgh]

CC @jkotas @marek-safar @eerhardt @danmoseley @ericstj @safern

[eerhardt]

cc @MichaelSimons @mthalman @richlander - FYI this can affect apps running in alpine docker, since Invariant mode is used there.

[danmoseley]

There's two parts here -- the first clearly needs this breaking change note, but do we expect that extending the casing table will actually break anyone?

[tarekgh]

There's two parts here -- the first clearly needs this breaking change note, but do we expect that extending the casing table will actually break anyone?

I did that per @GrabYourPitchforks request dotnet/runtime#55520 (comment). Technically, users of the Invariant mode will start notice differences.

[danmoseley]

I read that and I don't think I follow how it's a "substantial breaking change" (?) Perhaps it might be helpful to give an example of what a break would look like to a user.

[tarekgh]

Here is some example:

// This condition used to be false and now will start be true.
if ("Á".Equals("á", StringComparison.CurrentCultureIgnoreCase)) // or InvariantCultureIgnoreCase or OrdinalIgnoreCase
{
    // do something
}
else
{
    // do smoething else 
}

There are more examples I can add if this can help more.

[danmoseley]

Ah right - I was wondering if there's something more subtle. Yup, fair enough.

[tarekgh]

Real scenarios can be end users can notice string lists be sorted differently in their apps. But to be honest, I am not expecting anyone take dependency on the Globalization Invariant Mode behavior. I just agreed to @GrabYourPitchforks to document that just in case anyone can see that and proactively fix their code if they think will be broken.

[marek-safar]

This sounds to me more like a bug fix than a breaking change.