Hacker News Reader

Comment by secondaryacct | Hacker News Reader

As a new joiner from Java on applications that are decades old, I wish it would be more backward compatible.

I cant forgive they didnt find a way to fix WinForms, that we cant find the budget to move away from and limp along trying to upgrade out of.

But at least unlike Java, their GUIs do work well enough for a fraction of the maintenance cost of what I know. So meh, begging the sky to find anyone willing to do .NET in 2022 so I can go back to my cave lol. All the OG experts we interview are interested by our path to Java because they want out and Im like "but dude we'll teach you Java but we really need someone who has a clue in C#/.NET and likes it" :s

View on HN

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.

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

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.

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.

No idea where this Java elitism is coming from, dotnet and Java are ridiculously similar. I'd do dotnet for you in 2022 if you're willing to pay me more than my current corp with the same benefits, the language/platform is just fine.

Winform is also fine its just bad at transparency and most applications that are written using it are poorly written.

The usual stuff, Spectrum vs C64, Amiga vs Atari vs PC vs Mac, vi vs Emacs, Pascal vs C, C vs C++, ...... and naturally Java vs .NET, specially given J++ history and its relation to C#.

What do you mean about WinForms? Look at this https://devblogs.microsoft.com/dotnet/whats-new-in-windows-f... from a couple of months ago, you can still use it pretty well

As long as you are willing to put up with the bugs on the new .NET Core based designer, and can get new components that were rewritten for the new out-of-process architecture of the designer.

You can use it but maybe I didnt explain that I work mainly in performance optimization of heavy trading applications in electronic trading for a tier 1 investment bank.

No I cant explain why we wont finance a gigantic team to redo it all, but anyway: we need this to go faster, and I wish MS would fix WinForms to make them transparently faster rather than me profiling with despair "yes hum modals will always be a bit slow to redraw 50 controls, we could port to the new stuff but we're not sure it ll get better (but at least we ll benefit from more framework level optim) and it's so different we need a new guy" "then find a new guy", im told, and then every new guy who did some low latency GUI at our level (our app is very optimized but China will decuple volume eventually so...) will tell me he desperately wants out to move to java backend where all the fun is... which I cant deny since that s where I got extracted from urgently when half the .NET team left out of despair to go do Java in other banks lol.

I even grew to like .NET even if Ill never wrap my head around the build process and dependency management. Just a wish that MS would continue to optimize winform somehow so I wouldnt have to recode forms doing exactly the same thing. I suppose it s nonsensical since the new paradigm IS the optim but one can whine :D

WinForms sits on top of classic Win32 UI (HWND etc) architecturally, and that's what constrains its performance more than anything else. The way you get more perf is by taking over and rendering everything yourself, like WPF or WinUI does. But you can't do that while maintaining backwards compatibility - stuff like Control.Handle or IWin32Window.

There are millions of .NET developers ready and able to do whatever you need. I do find that the market for .NET is very underpaid though compared to the more popular stacks used at FAANG companies.

Are you really having that much trouble finding devs?

My group just hired our first .NET dev in years after many interviews.

Maybe they’re all working for the big banks. Or maybe all the .NET engineers realized they’re underpaid and have learned other technologies. My own experience is that outside of Azure, .NET has become extremely painful. FWIW, modern .NET and Visual Studio (anywhere other than ASP) is deserving of hazard pay, at the very least to compensate for the mental health cost of Visual Studio’s constant gaslighting.

I love my manager and team, but pretty soon I’m going to be telling them that I’m leaving, because .NET (on desktop and mobile) has given me 5+ years of very good reasons to hate it.

In what concerns the desktop, it has become a mess with the UWP failure, so they are now shoting in all possible directions, unfortunely.

Where are you hiring? I'm primarily a .net dev at a uni in the states. I'm surprised you're having trouble finding someone.

We do both stacks, on the backend we have the problem that most shops don't really buy into the whole .NET Core stack for Linux workloads story unless they happen to be Azure shops.

I have a clue about C#/.NET. Did it professionally for almost 2 years. That's why I don't like it.

Can you elaborate on why?

Sure. I like Linux and OSS. If anything happens that is unexpected I can trace it back to the source code that makes up my programming environment. I actually like C# as a programming language. It's .NET that's effed up. .NET development happens behind clicks and VS interfaces. The resulting configuration ends up in REALLY unreadable XML files, sometimes obfuscated behind object ids even. I like flat-file human-readable configuration. Also, Entity Framework can just curl up in a ball and die somewhere alone and crying. It's the most useless ORM I have ever worked with. And the documentation on it is just plain wrong often. Following a basic example can lead to results different from those advertised in documentation.

This is all born from experience. I was working on a project I believed in and came to it after the stack used was crystallized and unchangeable. I ended up throwing my hands up in disgust and leaving.

> .NET development happens behind clicks and VS interfaces.

That hasn't really been the case since .Net Core (aka .Net 5/6) replaced .Net Framework. You can develop entirely from the terminal if that is your choice or use Rider instead of Visual Studio if you want a cross-platform IDE.

> The resulting configuration ends up in REALLY unreadable XML files

You can now put the entire framework straight into the executables' directory, no more system-wide XML files. The concept of pre-installed .Net is legacy.

> This is all born from experience.

Of .Net Framework, which is deprecated.

Consider this toast burnt for life. I am not about to trust anything coming from Redmond for life. This is in spite of having great respect for things coming from Microsoft Research. I'll happily use their toy OS for my games but if I intend to do serious work I will not interact with Microsoft offerings except ephemerally.

Let's untangle this:

- .Net Framework made a bunch of unfortunate design decisions.

- You hated .Net Framework as a direct result.

- .Net Core (aka .Net 5/6) fixed the problems, went OSS, went cross-platform, de-coupled from proprietary tooling.

"Consider this toast burnt for life." I don't understand; if your disdain for .Net is meant to be technically founded then technical (and governance) improvements should address it but yet it doesn't here.

Can you unravel why them essentially going through your laundry list of problems and fixing them one by one has left the "toast burnt for life?"

Yes. I have never been burnt by these other software tools. I like them better. They work as advertised and any new features are new features, not fixes.

Not sure when your experiences are from, but in .net core they redid the csproj format which is much smaller and human readable (I often just edit the XML instead of using the designer). I think most (all?) of the source for .net core is available so well.

I dont know EF well but there is a rewritten core version

Reply on news.ycombinator.com