They had to rewrite the designer for .NET Core since the designer runs your own controls' code right during design time (pretty horrifying on one end, but also

They had to rewrite the designer for .NET Core since the designer runs your own controls' code right during design time (pretty horrifying on one end, but also enables a fairly integrated experience with custom controls). Since Visual Studio is based on .NET Framework the designer had to move out of process, as the only alternative would have been no designer at all. So that's a twenty-year old codebase, perhaps on both ends (Windows Forms Designer and Visual Studio alike) that now somehow has to be moved to different processes and different runtimes. Perhaps you have more luck with JetBrains Rider, although from what I've seen they simply host the very same designer in pretty much the same way as Visual Studio and thus are unlikely to fare any better here. The other option is the still-recommended workaround of keeping the .NET Framework project files around and do designer stuff with those. Also annoying, admittedly, but that's what I've been doing for now (well, for other reasons as well, as we sell a .NET UI component that still has to work in .NET Framework as well).