We abandoned .Net years ago before our third major product rewrite prompted by withdrawal of various bits of tech they said was the next greatest thing. AppFabric, WWF, WCF and Silverlight hit us hard.
Once burned, twice shy.
Once burned, twice shy.
The most supported UI frameworks from MS for Windows are WPF and WinUI 3. UWP is dead and WinForms (even though closest to something native to Windows) is probably going to end up in the land of forgotten (sorry nostalgic Windows devs, you have to face it eventually).
A "mess" is an understatement when the people who themselves develop Windows desktop apps have trouble explaining the landscape.
Everything boils back down to Win32, including WPF, WinForms, WinUI2, and WinUI3.
https://learn.microsoft.com/en-us/windows/apps/desktop/moder...
I don't understand this. I love C# as a language, but the idea that everyone is forced to upgrade every single library every 2 years is beyond unreasonable. I've recently run into a situation where some configuration behavior deep in ASP.NET just randomly changed between .NET 8 and .NET 10, and broke things. A runtime exception, not a compile-time one. What else is subtly broken in a DLL referenced by a reference of a reference? You may never know.
It seems like every software engineer has forgotten that code is ultimately math. All of the greats understood this, from the times of Alan Turing through the 1990s. Then all of a sudden it became some sort of a toy, a game for 20-year-olds to one-up each other, to move fast and break things. Somehow, as software development matured, it became less of a serious discipline. Now, we have an entire ecosystem where it's just accepted that any line of code you've ever written may just randomly break every 2 years. You can no longer just write a small C# library and expect to to continue to work forever. It's completely unacceptable in my view.
That said, I'd second the assertion that upgrades after .net6 are, for the vast majority of applications, trivial.
That's overstating the case. A library that targets dotnet 6.0 will often continue to restore and run in a dotnet 8.0 application. The notable exceptions are framework-aligned packages like Microsoft.Extensions. Most of the time you just need to bump the target framework in the props file, check it builds, run unit tests, and upgrade a few library packages that might need it.
So about that... when I started using .NET Core, it was bleeding edge and shiny, but it was to rewrite a Silverlight application, the only way to run it was Firefox ESR 54 (I think it was 54?) we thought "oh this is easy" only to find out that it was a colossal nightmare, EF didn't support some things, including Shapefiles, we had to force the support, get back a WKT from SQL Server, and send one back when we did updates, basically Entity Framework was mostly useless.
I also reverse scaffolded the existing database into EF compatible classes, so that saved us a ton of effort, the original idea was to be backwards compatible.
Best part? It never got used, when we found out they weren't using the project, my boss said, screw it, lets remake it in Python I know we can build it up quicker, and sure enough, it was done quicker than the C# rewrite, fastest rewrite I ever did, because he figured out the key things they actually needed, and trimmed the requirements to just those key things.
Sometimes rewrites don't need to be 1:1 especially if it's an internal only tool.
Anyway, lots of blood, sweat, tears, stress, etc from me as it was my first job in tech.
Boy do I have good news for you (I am half kidding). OpenSilver project lets you compile your Silverlight code to Web Assembly or iOS/Android/Windows/Mac.
You can dust off your code now.
Always just only stick to the actual framework itself and never rely on these offerings from Microsoft and you'll have a fine time.
That concept of "define an RPC interface and let the platform fill it" was ancient before WCF and continues to this day (I've got a bunch of tabs open for Cloudflare Durable Objects right now). The legacy problem with WCF was not but long term backward compatibility with the Bindings abstractions and XML config junk and SOAP Stack RPC. Without WCF native in the box in .NET 5+ it is harder (but not impossible) to build SOAP RPC monoliths. But so few businesses actually need SOAP and can't just switch to something more RESTful.
Silverlight was maybe ahead of its time given the growing popularity of Blazor WASM.