[ok123456]

Microsoft had remarkable native frameworks that they just decided to ditch. Many Forms and WPF applications still work and run entire businesses, but because of Microsoft's unnecessary churn, they are stuck with the legacy .Net Framework.

Yes. Many FOSS ecosystems don't even have adequate GUIs, but they never had them. Microsoft had them but then lost them. Every "modern" replacement requires you to import a whole browser in some form or another with all the baggage that comes with it, both in terms of development, runtime and security.

[ClickedUp]

> they are stuck with the legacy .Net Framework.

I develop WinForms applications at work and we use .NET Framework by choice, to aim for long-term stability and not the 'new thing'. We are not stuck we're loose. It's important to understand that MS Windows will never be able to get rid of the ability to run .NET Framework apps. Also, even though the new .NET supports WinForms, it's not a 1 : 1 port yet and we've done extensive testing on this. Not using .NET Framework would mean degrading the performance of the app (~30%). Try it out for yourself with a controls heavy application. I'm talking 100+ controls on a single app with real-time data fed through it. We use 3rd-party WinForms controls that's been in development for over 15 years. The GUI is modern and the performance excellent.

Words like 'legacy', in our case, means better stability and higher performance, and frankly, we neither trust nor care about Microsoft's opinion.

That said, I can understand that the new .NET is useful and an upgrade for those who wants cross-platform support among other things.

[ok123456]

If you were to fire up your IDE and start a new greenfield C# project, would .Net Framework be your first choice?

[ClickedUp]

Absolutely. Main reasons being 1) that we don't need any of the new features modern .NET can offer and 2) we specialize in mission critical, high performance apps

For example, recently a customer wanted a security solution, a filesystem journaling application, powered by a low-level FS kernel driver (C/C++) together with a managed .NET assembly to interop with our unmanaged driver DLL. Running on the highest altitude - on top of the driver stack - means handling, filtering, and intercepting a huge amount of filesystem requests before it reaches other system components. Therefore, performance is key.

In that scenario, using modern .NET we experienced nonstop deadlocks which froze the whole system. .NET Framework had no issues keeping up.

I can also think of other examples e.g. issues working with custom virtual filesystems.

So yes, NET Framework would be my first choice for standard Windows-only desktop applications.

[neonsunset]

In what scenarios can you make .NET Framework perform faster than .NET 8? The expected performance difference is 2 to 10x in favor of the latter. It’s not even a choice. If you can reproduce the issue, please consider submitting it to dotnet/runtime rather than choosing obsolete target.

[ClickedUp]

I already gave two examples 1) large-scale WinForms app with third-party controls and libraries and 2) Interop with FS kernel driver under heavy load

We were told to benchmark the performance on several computers using different hardware. In example 1 we calculated ~30% worse performance (worst case scenario!). In example 2 we had micro stuttering and system wide freeze (requiring reboot).

Again, in example 2, are we supposed to accept our customer computer freezing under load? In a high security, sensitive environment? You must be joking! Instead we delivered a solid product which do not freeze the system and we got great feedback. What's considered 'obsolete' is irrelevant to us. The word means nothing. Our benchmarks are of the highest importance.

Let me try again on monday though, I can reproduce the results then. Your claim piqued my curiosity, but I think you underestimate the specific requirements in which we work. Perhaps they've fixed something since last time we tried. I'm certainly willing to try again.

[exceptione]

Would be interesting to learn more. It seems like you know your stuff well, but could it be that your ported code doesn't do things like it should be done in modern .net?

Like using the apis that fully utilize spans. Also, I have the feeling (but nothing tangible) that old .net and .net core do behave differently wrt async stuff too.

[neonsunset]

That would be an exceedingly poor choice. Libraries have even started to drop NS2.0 target as it is too limiting or requires if-defs and extra maintenance effort for obsolete targets.

[alternatex]

Both Win Forms and WPF work with .NET 6+ though.

[ok123456]

Lots of asterixes and special cases. It's not just a drop-in replacement.