Hacker News Reader

Comment by hvidgaard | Hacker News Reader

You can run your WinForms application on the latest LTS version of dotnet, .NET6. As always, upgrading to a new version of the framework, means you have to migrate some parts of the codebase, especially from an older .net3-4. That isn't really that different from Java

If I'd have candidates that want out from .NET I'd be very intrigued and want to know why. Specifically, I don't want any that want out because the tech was changing rapidly. I can understand the overhead is somewhat annoying, but it's for the better and it seems to be a lot more stable again.

View on HN

VS 2022 WinForms designer for .NET 3.0+ can still not handle non-MS custom controls. If you want to create a user control yourself you need to sign an NDA with MS.

The API and behavior also changed, so it's not like updating the SDK version is enough. You need to fix every single form and control.

MS didn't botch the transition completely but it's very far from being a small task for larger applications maintained by relatively small teams.

> You need to fix every single form and control.

As anecdotal evidence, I certainly did not do this in my migration of several WinForms apps (one large and several small) to .NET 6. They flubbed the default font in .NET 5 so WinForms users had to wait a bit longer, but it's fixed in .NET 6. My forms all work fine in .NET 6 without change. It would have been infeasible to revisit all of the forms.

Do you have specific examples of APIs that changed? I can't think of any. I think changing the WinForms API would have taken a lot more effort than they actually invested to get it running on .NET Core. From where I'm sitting, it seems like they did the minimum necessary to get the existing DLL to run, and then spent 95% of their budget on the out-of-process designer rewrite.

Edit: I thought of one. They removed Menu; now there is only MenuStrip. I did have to make code changes for this and I totally forgot about it. It was minor though; we used MenuStrip anyway, there was just some code with optional support for Menu that I removed.

They did reference in several occasions that the likes of Telerik, ComponentOne, DevExpress,... had to jump in to enable such transition.

So I assume you aren't using such component libraries.

Yeah, that's correct; we only use the built-in controls and our own controls. Perhaps we don't use the functionality that was changed. I just edited my post above because I remembered I did have a breakage related to the removal of the Menu class.

You cannot create your own controls. It's impossible to integrate them with the VS designer unless you sign an NDA.

I don't mean a composition of existing controls but completely new custom controls. Yes, you can continue developing in code but nobody will develop winforms without a designer. Once you use a custom control in the control/form you will not be able to use the designer again until you remove the custom control. That is simply not acceptable for many developers.

There is much more low-level stuff like background behavior, event order and more which most developers simply don't notice, especially when only using Microsoft's controls.

I don't understand what you mean; we have tons of custom controls. I am looking at a .NET 6 project right now where I have a custom control that shows up in the toolbox under my project's group, and when you add it to the designer it renders (at design time) as it did before. It's clearly my OnPaint method drawing, etc.

I wonder if you're talking about a previous version of .NET Core? .NET 6, very recently released, is the first version where legacy WinForms apps can start to upgrade. There were blockers in previous .NET Core versions. If you're maybe talking about .NET Core 3.1, WinForms was not at all ready in that version. It was almost there in .NET 5 but they made a mistake with the default font handling that broke legacy apps, but they both fixed that bug and finished the designer for .NET 6.

The designer isn't the runtime. Custom controls work fine in the application; it's the click-and-drag builder in Visual Studio that doesn't work. I don't miss it.

> If I'd have candidates that want out from .NET I'd be very intrigued and want to know why.

Every time I change jobs I always try. It's not that I hate .Net, it's just that I want to try something different.

.Net is awesome, but it's always useful to see how other languages and platforms do things. For example, compiler enforced null checking in C# is lousy compared to Swift or Rust.

In .NET 6, there is new "EnableNullable" directive that will do that. It's on by default for new projects.

It's horrible.

For example, it treats Linq's .First() as nullable. (.First() throws an exception, .FirstOrDefault() returns null.)

Type.Name is also treated as nullable.

I didn't encounter any issues like that when I tried Swift and Rust.

That is not true.

LINQ's First() correctly returns a non-nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,11

FirstOrDefault() correctly returns a nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,33

typeof(type).Name is MemberInfo.Name, which is also not nullable: https://source.dot.net/#System.Private.CoreLib/MemberInfo.cs...

I checked both .NET 5 and .NET 6. They have identical nullability.

Then how come I get a compiler error if I don't check the result?

Did you perhaps enable null checking for an older version of the framework (in which the standard assemblies don't have the appropriate annotations)? This works just fine when targeting .NET 6:

   object[] xs = {};
   var n = xs.First();
   n.ToString();

That is a very valid reason.

I’m not sure there is enough of a benefit from moving away from .Net Framework for Windows Forms applications. I’m not planning on migrating my apps for the foreseeable future.

Reply on news.ycombinator.com