Tagging subscribers to this area: @ajcvickers
See info in area-owners.md if you want to be subscribed.

Don't block on me for this; happy to go with what those in the know deem best.

Talking it over with @ericstj and @tarekgh, we thought of the following options to fix this issue:

1. Opt ComponentModel.Annotations out of UseSystemResourceKeys behavior.
   • This has the drawback @joperezr points out above - it will bring in ResourceManager when someone is using ComponentModel.Annotations.
2. Hard-code the "default value" resource string in the ~30 places where strings are shown to end users.
   • This has the drawbacks of duplication in both code and increased binary size.
3. Have the SR class generator generate the "default value" resource strings
   • This also has the drawback of increased binary size, but it is more maintainable than (2) above.
   1. A potential sub-option here is to only generate the "default value" strings for the browser build. But since this library ships in an OOB package, that is going to make packaging more complicated.
4. Teach the ILLinker to do the string substitution (from the .resources file into the IL)
   • This approach was discussed in High-level option 2: Introduce way to disable localization support #34057 (comment)
   • This isn't going to be feasible to implement in 5.0.

I've decided to take option (3) above and have updated this PR for it. The increase in size of the System.ComponentModel.Annotations assembly in the Windows x64 shared framework goes from 152 KB to 163 KB on my machine, which isn't significant. If we really think we need to save those 11 KB, we can look at enabling this only for the browser build (and eventually the ios and android builds).

@ajcvickers @marek-safar - any thoughts/opinions here? I am going to propose we backport this change into 5.0.

@ajcvickers I really don't have enough context on how this all works to have any useful thoughts.

@eerhardt I don't know what exactly GenerateResxSourceIncludeDefaultValues does but it sounds like a sensible compromise. I don't think we should target only browser for this setting as there are other size sensitive configurations in master.

I don't know what exactly GenerateResxSourceIncludeDefaultValues does

It causes our SR class code generation to go from:

    internal static partial class SR
    {
        internal static string @EmailAddressAttribute_Invalid => GetResourceString(
            "EmailAddressAttribute_Invalid");

to now be:

    internal static partial class SR
    {
        internal static string @EmailAddressAttribute_Invalid => GetResourceString(
            "EmailAddressAttribute_Invalid",
            @"The {0} field is not a valid e-mail address.");

Which means the resource string is now hard-coded in the C# file. This string gets passed in as the "defaultString" in this method:

Which means that when UsingResourceKeys() is true, that hard-coded string will be returned instead of the resourceKey string.

I don't think we should target only browser for this setting as there are other size sensitive configurations in master.

👍 , agreed. Thanks for the input.

/backport to release/5.0-rc2

Started backporting to release/5.0-rc2: https://github.com/dotnet/runtime/actions/runs/267713992