Interesting submission considering it's still in draft status.
As a user of .NET since version 2.0 though, I'm impressed and excited by how the platform has evolved and how much performance has become a focus.
As a user of .NET since version 2.0 though, I'm impressed and excited by how the platform has evolved and how much performance has become a focus.
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
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.
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.
- .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?"
I dont know EF well but there is a rewritten core version
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
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.
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.
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.
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.
object[] xs = {};
var n = xs.First();
n.ToString();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.
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.
So I assume you aren't using such component libraries.
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 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.
Winform is also fine its just bad at transparency and most applications that are written using it are poorly written.
Are you really having that much trouble finding devs?
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.