Does Globalization Invariant Mode affect exception messages locations in .NET 6.0?

[kiminuo]

Hi,

I have turned on Globalization Invariant Mode in a C# project by adding the following line in my Project.csproj file:

<InvariantGlobalization>true</InvariantGlobalization>

However, even after this modification, it happens that exceptions (coming from .NET libraries) are translated (probably based on .NET runtime and its localization or computer localization).

Is InvariantGlobalization supposed to prevent that or not? I mean is my observation correct?

Thank you!

PS: My question might or might not be related to #40427.

[steveberdy]

Exceptions messages are pulled from .resx files, such as from here:

runtime/src/libraries/System.Private.CoreLib/src/System/IO/File.cs

Line 59 in a6de632

throw new ArgumentException(SR.Argument_EmptyFileName, nameof(destFileName));

As far as I can tell, there are some translated resx files, such as for source generation and tests, but not for exception messages.

There is some information in this issue: #46656

[daiplusplus]

@kiminuo I'm not sure.

The documentation for InvariantGlobalization that you linked to says this (emphasis mine):

• When enabling the invariant mode, all cultures behave like the invariant culture.
• Culture names (English, native display, ISO, language names) will return invariant names.

• Now, inside most .NET BCL assemblies, string resources for exception messages are in the internal class SR.
• These class SR all wrap ResourceManager.
• When you use SR or ResourceManager you'll end-up invoking ResourceManager.GetString, which (by default) passes CultureInfo.CurrentUICulture into ResourceManager.GetFirstResourceSet which uses CultureInfo.Name - which is used to locate and load satellite assemblies to load localized resource strings, just like those used in exception messages.

So based on my understanding of what I've seen so far, I would think that <InvariantGlobalization>true</InvariantGlobalization> will cause ResourceManager to always prefer non-satellite assemblies for resources, which (as as far as I know) are always en-US.

[kiminuo]

Thank you @Jehoel!

Tagging @tarekgh, @Chiramisu and @333fred as they responded in #40427 whether some of them can just make it clear what the current behavior is 🙏 with regard to InvariantGlobalization.

[danmoseley]

The core libraries are not currently localized, as noted above. Some want then localized (to show messages to users, or because the developers prefer their own language) and many do not (because they can search for the errors on the internet, and they can read the messages that their users encounter). There's an issue discussing this somewhere. If we end up localizing them (there's currently no plans) I expect we would offer a switch for the app author to opt into localized exception messages if they wish. Meantime we take care to pull messages from resources so that localization would be easy.

As noted above components in the SDK like source generators or MSBuild are localized.

[daiplusplus]

@danmoseley That problem was solved 50+ years ago by using non-localized exception-specific error-codes. Windows has them as HRESULT of course - why isn't that an option?

_{(Though I'd argue that the original design of .NET's exception system - where it's heavily reliant on the localized Message string - was a mistake - (but, yes, it's easy to criticize). Out of curiosity, how big a break is it to add extra fields and members members to Exception that could be used to convey language-invariant exception details?}

[danmoseley]

That ship has sailed as you point out, but IMO exception messages have many advantages. There is no need to look up what they mean. They can be finer grained than error codes are in practice, and include more info. And other reasons.

With respect to changing Exception, that would make it bigger for everyone, and I doubt much code would ever use it. There is already a Data field you can use, but I've hardly seen it used.

I believe the linker (?) allows you to trim all messages out of our resources and leave only the resource IDs and any substitutions. Neither are localized of course.

[tarekgh]

To answer the original question in this issue:

The resource lookup depends on the CultureInfo. If no specific culture is specified during the resource lookup request, then CultureInfo.CurrentUICulture will be used for the resource lookup. When enabling Globalization Invariant mode, in .NET 6.0 we only support InvariantCulture by default. That means the resource lookup will always be performed using the Invariant culture and most of the resources would be picked up from neutral resources specified by the attribute NeutralResourcesLanguageAttribute on the code assemblies.

If you are using .NET 5.0 or NET Core 3.1, then in Invariant mode, we allow creating different cultures and resource lookup will just work as it does in outside Invariant mode. The only difference will be the fallback to parent cultures will not work in the Invariant mode as it is not supported there.