.NET Core 3.1 WindowsDesktop application can fail when rolled forward to .NET 5 preview

• .NET Core Version: .NET Core 3.x -> .NET 5

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

Problem description:

The System.Windows.Forms.Design.Editors.dll assembly has been removed in .NET 5, which can cause applications built with .NET Core 3.x to fail if they used a type from that assembly and are permitted to roll forward on major versions.

Expected behavior:

The application should not fail. Instead, a System.WinForms.Forms.Design.Editors.dll should be included that contains type forwards for all of the types that were moved out of that assembly. In this way, WinForms on .NET 5 remains binary compatible.

Minimal repro:

1. Create a .NET Core 3 application.
2. Add code that references a public type from System.Windows.Forms.Design.Editors.dll, e.g. AnchorEditor.
3. Build it
4. Run it
5. Copy the app to a VM with only .NET5 SDK installed (or remove .NET Core 3.x SDK form your workstation)
6. Modify a <app name>.runtimeconfig.json with the following content (update the .NET5 SDK version as necessary):

   {
     "runtimeOptions": {
   	"tfm": "netcoreapp3.0",
   	"rollForward": "LatestMajor",
   	"framework": {
   	  "name": "Microsoft.WindowsDesktop.App",
   	  "version": "5.0.0-preview.2.20119.5"
   	}
     }
   }
   

7. Run the application and ensure that the code that used the type from System.Windows.Forms.Design.Editors.dll executes.

[EDIT] updated the repro steps

[weltkante]

@RussKie @merriemcgaw just FYI if you intend to preserve binary compatibility between 3.x and 5.0 you cannot add proper generic collection support (#2644). Return types of GetEnumerator have to change in order for foreach to pick it up; this will break applications which roll forward from 3.x (just tested). Since loops over collections are probably going to be pretty common you can’t treat it as an exceptional case, it’ll probably affect every nontrivial application rolling forward from 3.x

IMHO requiring a recompile for 5.0 is not entirely unreasonable and its probably one of the better chances to modernize winforms, it’ll probably only get harder from there on.

So ultimately you’ll have to make a strategic decision here what your goal for the 3.x/5.0 transition is, and the sooner its done and communicated the better.

[weltkante]

@RussKie I’m just saying that if #2644 is implemented the work done here doesn’t matter because roll-forward will fail anyways as soon as anyone has an foreach loop (which is pretty likely). Giving people the false impression that roll-forward will work in “some cases” may be counterproductive because ensuring that nobody has an foreach loop over a WinForms collection will be pretty much impossible (its enough if a single library has such a loop). Personally I’d prefer a clear error message that you need to recompile (or dropping #2644 if the impact is considered too large). In either way I wanted to make sure you are aware of the consequences the not yet merged PR would have.

we don’t expect to build a version of the Designer for each .NET version. Other API proposals likely won’t have a significant effect on the Designer, as those do not touch type editors and type converters.

You’ll have to make sure not using foreach loops over WinForms collections in the designer then (probably can pass the collection through a helper method so the foreach doesn’t see the specific class you are iterating over)