Runtime crash due to localization and the way designer serializes keyboard shortcuts

[filipnavara]

• .NET Core Version: 3.1.2

• Have you experienced this same bug with .NET Framework?: No

Problem description:

Steps to reproduce:

• Create a blank .NET Framework WinForms application with a Form.
• Set the Form to Localizable = true in the designer.
• Add context menu with single item.
• Set the ShortcutKeys on the item to Control+C.
• Observe that the application works just fine on .NET Framework 4.8.
• Switch locale at startup to German by System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("de-DE");
• Observe that the application still starts just fine on .NET Framework 4.8.
• Change the application to target netcoreapp31 and it immediately crashes on startup.

The reason for the crash is that the .resx file contains the shortcut key serialized as

  <data name="booToolStripMenuItem.ShortcutKeys" type="System.Windows.Forms.Keys, System.Windows.Forms">
    <value>Ctrl+C</value>
  </data>

Notice that the serialized value starts with Ctrl, not Control. It is produced and consumed by KeysConverter class that is locale dependent. While the value Control would work in any locale due to the fallback to names in the Keys enum the value Ctrl is taken from a dictionary that contains localized names. On .NET Core 3.1 in the German localization the name for Control key is Strg. Thus the value Ctrl+C in the resource file is invalid and causes conversion error at runtime.

Notably we migrated a large project from .NET Framework to .NET Core where we hit this issue. The .NET Framework also has similar issue in code but the localizations may differ which would explain why the problem is not hit.

Manually fixing the value in the .resx file to Control+C makes the application work in any locale but any further editing in the designer breaks it again.

Expected behavior:

No crash. The resources generated by the designer should be locale independent.

Minimal repro:

Here's the sample app created using the steps above. It is multi-targeting both .NET Framework and .NET Core so it can run in both variation from inside Visual Studio.

WindowsFormsApp2.zip

[janbaltus]

From comments it seems CTRL being localized as STRG is causing crash.
Both Ctrl are localized.
If string is not ment to be localized it need to be locked by instruction.

Microsoft.DotNet.Wpf\src\UIAutomation\UIAutomationClientSideProviders\Resources\xlf\Strings.xlf
0; "KeyCtrl"
System.Windows.Forms\src\Resources\xlf\SR.xlf
0; "toStringControl"

Can you please confirm which one of above is the functional key?

[filipnavara]

toStringControl is the problematic one.

[janbaltus]

When we compare resource from .Net Framework same string ID was used and localized in the past

LocComment=(SLE)It's used by the KeyConverter to localize display of menu shortcuts, it can be translated into whatever is printed on the keyboard for this key (eg. ALT) in the corresponding language.

So from our point of view this might be localizability issue in .NetCore.
@RussKie can you please check?

[janbaltus]

please find xls with all tostring occurrences:
.net.xlsx

[weltkante]

Desktop Framework also stores ShortcutKeys localized in the resx file yet doesn't run into this issue. I don't think this is a localization problem as having localized ShortcutKey resx strings works in Desktop Framework, its more likely that this is a tooling issue.

  <data name="booToolStripMenuItem.ShortcutKeys" type="System.Windows.Forms.Keys, System.Windows.Forms">
    <value>Ctrl+C</value>
  </data>

Note the type="System.Windows.Forms.Keys, System.Windows.Forms" which I think means the resx-compiler is supposed to translate this into the enum, not the runtime on the end user machine. With an enum stored in the binary resx resource instead of a string the ShortcutKeys property should be stored language-independent.

I suspect the .NET Core resx compiler ignores this instruction and stores the type as plain string, causing it to be translated at runtime, which fails depending on the users UI culture.

Comparing the binary resx data between a Desktop Framework and .NET Core build may be able to confirm if this assumption is correct.

[weltkante]

Yeah can confirm the tooling is badly designed here, .NET Core uses a new resx format which prefers string serialization over binary serialization.

On the reader side they do ConvertFromInvariantString which shows up in the stack trace as source of the error.

But I guess on the writer side they don't roundtrip through TypeConverter to emit an invariant string, they probably just emit the resx string directly into the resource. Since the whole point of resx files is localization nobody should expect resx resources to already be in invariant culture, so this is probably a bug in corefx tooling. I don't know where the source of the tools is but IMHO they should fix it and do something like

// get the type converter for the type specified in the resx source
var tc = TypeDescriptor.GetConverter(typeof(Keys));

// roundtrip through TypeConverter once to ensure data is invariant culture
serialized_value = tc.ConvertToInvariantString(tc.ConvertFrom(resx_value));

[filipnavara]

The whole point of the CoreFX tooling was to avoid deserialization and reserialization of the resources and loading all the assemblies with the necessary converters (dotnet/corefx#36906). /cc @ericstj

[weltkante]

Never mind, WinForms KeysConverter is also totally broken, in that it doesn't implement ConvertFromInvariantString correctly. It just ignores the culture being asked for and initializes itself with the CurrentCulture.

Sorry for the multiple posts, seems like I was digging down a rabbit hole :-) It may very well be that corefx resx writer already performs the culture-invariant transform described above and the error is on WinForms side because KeysConverter doesn't support ConvertFromString correctly when given a specific culture.

You should still double check that the resx tooling is outputting the resx data in invariant culture, otherwise fixing this in WinForms just for the Keys property is possible, but it will still fail for 3rd party designer properties.

[weltkante]

@filipnavara @ericstj you can't avoid running the TypeConverter on build time if you want a culture-invariant serialization format. Serializer and deserializer must be symmetric in what culture they emit and expect. (Well, you could record the expected culture and operate on it directly when deserializing instead of having a culture-invariant format ...)