4 ms·

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 migr

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.

gwbas1c 5y ago
> 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.
- starik36 5y ago
  In .NET 6, there is new "EnableNullable" directive that will do that. It's on by default for new projects.
  - gwbas1c 5y ago
    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.
    - Genbox 5y ago
      That is not true. LINQ's First() correctly returns a non-nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,11 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 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,14 https://source.dot.net/#System.Private.CoreLib/MemberInfo.cs... I checked both .NET 5 and .NET 6. They have identical nullability.
      - gwbas1c 5y ago
        Then how come I get a compiler error if I don't check the result?
        int_19h 5y ago
        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();
- hvidgaard 5y ago
  That is a very valid reason.
foepys 5y ago
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.
- electroly 5y ago
  > 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.
  - pjmlp 5y ago
    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.
    - electroly 5y ago
      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.
tonyedgecombe 5y ago
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.

gwbas1c 5y ago

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

starik36 5y ago
In .NET 6, there is new "EnableNullable" directive that will do that. It's on by default for new projects.
- gwbas1c 5y ago
  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.
  - Genbox 5y ago
    That is not true. LINQ's First() correctly returns a non-nullable type: https://source.dot.net/#System.Linq/System/Linq/First.cs,11 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 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,14 https://source.dot.net/#System.Private.CoreLib/MemberInfo.cs... I checked both .NET 5 and .NET 6. They have identical nullability.
    - gwbas1c 5y ago
      Then how come I get a compiler error if I don't check the result?
      - int_19h 5y ago
        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();
hvidgaard 5y ago
That is a very valid reason.

foepys 5y ago

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.

electroly 5y ago
> 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.
- pjmlp 5y ago
  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.
  - electroly 5y ago
    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.

tonyedgecombe 5y ago

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.