runtime: Crash in GlobalizationNative_GetSortHandle related to System.Globalization.GlobalizationMode

If you move LoadIcu to explicit static constructor on Unix, internal static bool UseNls => false; will need to trigger that static constructor (it does not need to trigger it today). It would have bad side-effects as well. It won’t be possible to optimize UseNls into nothing as it gets optimized today.

In this case I assume we’d need to keep both branches when InvariantGlobalization=false at publish time, one in case the load succeeds, one in case it fails.

That would completely undo any size gains made by https://github.com/dotnet/runtime/pull/47999

If memory serves, the browser fallback here was primarily added to keep things limping along while we were integrating the icu data loading changes through the stack. If the fallback is causing issues we can probably turn it back into an error now (and update the error message).

I’ve opened https://github.com/dotnet/runtime/issues/49391 to track this.

The illink XML doesn’t look right:

    <type fullname="System.Globalization.GlobalizationMode">
      < ... >
      <method signature="System.Boolean get_Invariant()" body="stub" value="false" feature="System.Globalization.Invariant" featurevalue="false" />
    </type>

I don’t think we can make a promise that Invariant will always be false.

On Browser, we will fall back to Invariant if ICU cannot be loaded. Taking the ICU codepaths in that case won’t lead to happiness:

https://github.com/dotnet/runtime/blob/79ae74f5ca5c8a6fe3a48935e85bd7374959c570/src/libraries/System.Private.CoreLib/src/System/Globalization/GlobalizationMode.Unix.cs#L25-L37

This is not a publish-time constant, at least not in browser.

My assumption is that LoadICU() line is getting trimmed because I changed Xamarin apps to explicitly set <InvariantGlobalization>false</InvariantGlobalization>. That feature switch rewrites the method that calls into this line to just return false; all the time. Thus, this line isn’t getting called anymore.