Project-system: The Managed Resource Editor fails to show content of resource files created with the Core Designer

[KlausLoeffelmann]

Visual Studio Version:
Visual Studio 2019 >=16.5.0 Preview 1.0.
(The necessary Core-Designer ResourcePicker feature has not been merged at the time of creating this issue, though - see _Steps to Reproduce_).

Summary:
With the WinForms Core Designer, local resource files (later also project resource files) for Forms or UserControls are added, whose images content is not created by the runtime but by the out-of-proc Designer Surface Process. The images that end up in the resource files are thus based on the corresponding .NET Core type and cannot be displayed by the Managed Resource Editor.

Steps to Reproduce:
Since the feature is not yet publicly available in the Visual Studio previews, the easiest way to repro is to use the attached sample project to track the bug.

ManResourceEditorRepro.zip

1. Load the attached project in Visual Studio.
2. Expand the branch Form3.cs
3. Double-click on Form3.resx to start the Managed Resource Editor to show the content of the file.

Expected Behavior:
The Managed Resource Editor should show the image content of the resource file.

Actual Behavior:
The Manage Resource Editor shows this.

User Impact:
Users can neither show or edit Images, which have been added to the resource files via the .NET Core WinForms designer.

[davkean]

@dmonroym @davidwengier What's the status of this bug?

[davidwengier]

We thought this was the same bug as was previously fixed with the resource editor (and I thought this issue was already closed), and that the issue was simply that the project had been created before that fix went in. With the repro in https://github.com/dotnet/winforms-designer/issues/1119 I can see now this is a separate issue of two systems not agreeing with each other.

The winforms designer has its own TypeNameConverter function here which obviously doesn't have the workaround we put in for #5589. This isn't a problem for the winforms designer as it runs in .NET Core. With this repro though, the bug occurs when opening a .resx file written by the .NET Core winforms designer, in the .NET Framework resource designer.

We should see if we can have the resource editor map the .NET Core types back to .NET Framework types when reading in the resource file, which is similar to what it used to do when writing the file (and maybe even did, before I removed that code? ¯\_(ツ)_/¯)

The long term fix for this will be https://github.com/dotnet/winforms-designer/issues/236

@KlausLoeffelmann you could potentially update the winforms designer with the same workaround as in the VS change that fixed the resource editor, or even possibly somehow remote the MultiTargetService from VS and use it directly? That way at least we wouldn't be maintaining two allowlists of types.

@dmonroym we can talk about this tomorrow.

[KlausLoeffelmann]

The _MultiTargetService.cs_ which you referred to we no longer in use. (So isn't any of the code which is in the _Legacy_ folder.) We keep that code there for now only for easier lookup purposes. Also, I am not sure why the long term fix for this will be https://github.com/dotnet/winforms-designer/issues/236. That issue just referrs to the Winforms Designer part of the Resource Editor (so, the actual Type Editor which adds an Image Resource for example), but it does not refer to any functionality of the project system. (I'd agree though, we'd need a better description or a better title to describe the scope):

Let me see, what options we have. The serialization is completely done in Core - VS just gets the complete resource content and the CodeDom back, so, I need to understand what the options are.

[davidwengier]

I may have misinterpreted what that issue is, but I think the long term fix for this issue is a .NET Core Resource Editor that is OOP and remoted into VS much like the WinForms Designer.

[KlausLoeffelmann]

Yes, I think so too.
But I may have a quick and dirty solution for now. I keep you posted.

[DustinCampbell]

@KlausLoeffelmann: Any update here? It sounds to me like the adding the same hack to the classic designer code base is the way to make this work in the short term.

[Amy-Li03]

Verified this issue on VS latest build: 16.9.0 Preview 3.0 [30820.7.main], the error is changed after double-click on Form3.resx, details please see the following screenshot: