3 ms·

That's definitely true but they did a good job supporting their tech once it was released. My company has been using WinForms on .NET Framework for over 10 yea

by foepys 5y ago

That's definitely true but they did a good job supporting their tech once it was released. My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well. Microsoft even added HiDPI support to it. When Microsoft announced they wanted to bring WinForms to .NET Core 3, we were initially very happy as it meant we could switch to .NET Core. But then they did all kinds of shenanigans with it and completely rewrote the designer for .NET Core in Visual Studio, which is now riddled with bugs and crashes constantly. You cannot even load your own custom controls into it. I mean, you can, just get Microsoft to let you sign an NDA to get access to the APIs...

beermonster 5y ago
> My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well. Despite WPF being preferred amongst developers, WinForms solves most use-cases well. I’ve not really kept up with Microsoft UI developments but I’d be interested in seeing any cross-platform UI toolkits they develop now or in the future just as an alternative to gtk/qt
- pjmlp 5y ago
  The problem is that many features in Forms like data binding or layouts, have bugs, which happen to be only fixed on WPF, because that was the new boy in town. So when you move beyond VB6 style of applications, there are several head scratching moments.
  - lbriner 5y ago
    Sadly this is their policy across the board. Even though things like dotnet core 3.1 is supposed to be LTS, when you report a bug, you are most likely to get the response, "we will only fix it in .Net 5" as if upgrading everything is a 5 minute exercise. For a company who turns over an enormous amount of money and employs 10s of 1000s of people, you would have thought they could support these separate frameworks with dedicated teams of 10-20 reasonably high calibre devs.
ygra 5y ago
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).
mattmanser 5y ago
No they didn't. Take a look at what happened to silverlight or UWP. You just happen to be working in the one tech they actually carried on supporting.
- pjmlp 5y ago
  UWP is still supported, that is what WinUI is built on. The problem is that they now seem to somehow carrying that flag forward on top of XAML Islands, with an endless list of bugs.
tonyedgecombe 5y ago
I had a lot of problems adding HiDPI support to a moderately complex WinForms application. It was a huge time sink.

by foepys 5y ago

beermonster 5y ago

> My company has been using WinForms on .NET Framework for over 10 years now and it's working really, really well. Despite WPF being preferred amongst developers, WinForms solves most use-cases well. I’ve not really kept up with Microsoft UI developments but I’d be interested in seeing any cross-platform UI toolkits they develop now or in the future just as an alternative to gtk/qt

pjmlp 5y ago
The problem is that many features in Forms like data binding or layouts, have bugs, which happen to be only fixed on WPF, because that was the new boy in town. So when you move beyond VB6 style of applications, there are several head scratching moments.
- lbriner 5y ago
  Sadly this is their policy across the board. Even though things like dotnet core 3.1 is supposed to be LTS, when you report a bug, you are most likely to get the response, "we will only fix it in .Net 5" as if upgrading everything is a 5 minute exercise. For a company who turns over an enormous amount of money and employs 10s of 1000s of people, you would have thought they could support these separate frameworks with dedicated teams of 10-20 reasonably high calibre devs.

ygra 5y ago

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

mattmanser 5y ago

No they didn't. Take a look at what happened to silverlight or UWP. You just happen to be working in the one tech they actually carried on supporting.

pjmlp 5y ago
UWP is still supported, that is what WinUI is built on. The problem is that they now seem to somehow carrying that flag forward on top of XAML Islands, with an endless list of bugs.

tonyedgecombe 5y ago

I had a lot of problems adding HiDPI support to a moderately complex WinForms application. It was a huge time sink.