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

• .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

[RalphLAtGitHub]

To whom it may concern at Microsoft: It is extremely annoying that Microsoft is unable to fix this bug after almost two years, let alone provide a timeline for solving the problem. if I did my job like that, I would be bankrupt!

[weltkante]

Desktop Framework:

• VS designer interacts with the Property Grid in the Current Culture (OS language) but CurrentUICulture is the VS installation language - in other words the developer usually sees and edits the localized version in the designer (but for KeysConverter he will see keys localized according to his VS language because SR string resources in its implementation use CurrentUICulture not CurrentCulture)
• VS designer stores in resx with invariant culture. This breaks for KeysConverter because it keeps operating on CurrentUICulture which still is the VS installation language.
• msbuild deserializes resx entries with invariant culture. KeysConverter still uses CurrentUICulture which cancels out the bug when building from within VS, but it will fail the build when run outside VS and the OS and VS language does not match (one of my machines has english VS on german OS and could not build the test project outside VS on this machine)
• runtime deserializes with BinaryFormatter (culture is irrelevant) so the bugs above never mattered for end users as long as your build environment had a consistent language (and if it didn’t you’d get build errors instead of runtime errors)

.NET Core

• VS designer doesn’t support custom controls yet so I couldn’t check how CurrentCulture and CurrentUICulture are used
• msbuild does not use TypeConverter, it just takes the string from resx
• runtime deserializes with invariant culture

Asumming VS designer for .NET Core will be implemented analogous to Desktop Framework it will interact with the developer in the Current Culture and serialize to resx with Invariant Culture - then everything will play out fine for a correctly implemented 3rd party TypeConverter.

That leaves the broken WinForms KeysConverter to fix. The new resx writer implementation moves a build-time localization issue (which either canceled out itself or resulted in build failures) into runtime errors, you’ll have to fix KeysConverter and support serialization/deserialization with the requested culture, otherwise the new resx format will never work correctly with KeysConverter.

You also might have to consider providing a migration path, because after fixing KeysConverter the VS designer will no longer be able to read resx forms made on non-english VS installations (both made in .NET Core before the fix and those migrated from Desktop Framework will fail to open in the designer). Considering manual fixup of the resx files is possible you may get away without providing an automated resolution in the .NET Core VS designer.