Project-system: Resource Editor fails to add non-string resources in .NETCore projects

[ericstj]

Visual Studio Version:
16.0.2

Summary:
Resource editor is trying to activate .NETCore types in desktop process, resulting in a failure to load the assembly which doesn't exist in desktop.
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/692319

Given the resources editor only supports a small set of types that are in the framework, I don't think we need to remote this part of the designer into a .NETCore process. Instead we could have the editor read TypeForwardedFrom on these types, then activate that identity which will be the desktop identity. We can ensure that for the set of types the resource editor uses remain serializeable on .NETCore and support round-trip serialization with desktop (since this is already needed to support .NET Framework assembly reuse in Core). If my assumption about "small set of types" is not correct we may need to revisit this direction.

Steps to Reproduce:

1. create a new .netcore 3.0 winforms project

2. open resources

3. try to add image

Expected Behavior:
image successfully added

Actual Behavior:
Error adding the image

User Impact:
Cannot add non-string resources to resx in .NETCore3.0 projects.

This is dependent on the work in MSBuild to support handling the non-string resources in core-MSBuild. /cc @rainersigwald @DustinCampbell @dreddy-work @nguerrera @merriemcgaw

[Pilchie]

FYI @davidwengier and @jjmew

[ericstj]

Can this be marked as required for .NETCore 3.0?

As part of this issue can you also take a look at the behavior of the "Other" tab in general and define a behavior that makes sense for .NETCore projects? Some ideas:

1. Disable editing and instantiation.
2. Permit editing but do not instantiate types, merely write data directly to resx.
3. Permit editing but only instantiate some subset of types which are known to be supported.

Any of these would be legitimate from our perspective.

/cc @merriemcgaw @rainersigwald @nguerrera @DustinCampbell

[dmonroym]

Relates to AB#897797

[ericstj]

Any updates on this? I believe this one is pretty important to land the WinForms scenarios.

[dmonroym]

Started investigation towards it and it's my main focus for next week. Will update once there's been more substantial work done.

[davkean]

@dmonroym Are we taking the simple approach first where we just map .NET Core types -> .NET Framework?

[davkean]

@ericstj We're looking at taking an easy approach where we continue to use the .NET Framework type names both inside the designer itself and the persistence format. Can we rely on those names to be correctly unified on .NET Core? If not - then it makes this significantly harder.

[ericstj]

Using the desktop identity should be sufficient for framework types. What are you going to do about the "other" tab? That can have any type, including user types.

[davkean]

@dmonroym You'll need to handle byte[] as well.

Until we have a reusable OOP service coming from WinForms designer work that we can, we won't show any result in the value column.

[ericstj]

Ok, I'm guessing folks working on the designer understand that they'll likely need to do the resx-writing from that OOP service, or at least be providing the serialized content from there? It won't work to have live user types in the desktop process.

[merriemcgaw]

We've got an issue in https://github.com/dotnet/winforms-designer/issues/236 to track the work that needs to be done. I'll reference this issue so we don't forget it.

[merriemcgaw]

@Tanya-Solyanik FYI.

[davkean]

~Fixed in https://github.com/dotnet/winforms-designer/issues/236.~

Fixed in https://github.com/dotnet/project-system/pull/4900, long term tracked by https://github.com/dotnet/winforms-designer/issues/236.

[nguerrera]

I'm confused about this being closed now. The resource editing will be taken over entirely by the winforms designer?

[ericstj]

@nguerrera I think #4900 should enable editing of the known types. I think the open issue was what goes on with the "other" tab, and that portion is being tracked in https://github.com/dotnet/winforms-designer/issues/236.

[davkean]

My bad, I linked the wrong bug.