[cweagans]

> - .NET is not really viable for non-server work. There is embedded/desktop stuff but you're going to have a headache outside of servers.

As an outsider to this ecosystem, desktop development is one of the things that has me interested in C# at all (built in windows stuff + Avalonia + Xamarin and the like).

Can you elaborate this?

[Guid_NewGuid]

So I think the current/new desktop approach is MAUI, maybe, it's hard to keep track. When evaluating Microsoft/.NET stuff I think the safest approach is to ignore anything they come out with and check back in 4 years to see if it still exists. Desktop is the worst for this.

Winforms and WPF are still solid choices if you need a Windows only UI and I think Avalonia is still going and might be good, I haven't really had an opportunity to evaluate it. But I think desktop still lacks a compelling cross-platform solution post-WPF and adopting early solutions from Microsoft will cause you many headaches and much sadness.

[WorldMaker]

MAUI is the continuation/rebrand of Xamarin, most especially Xamarin Forms (as some of what used to be Xamarin is now just baked into .NET at lower levels). It's still more cross-platform mobile focused (iOS and Android seem to be the best tested platforms), though with support for full WinUI 3 and macOS Catalyst the lines are blurrier than ever between mobile and desktop development, especially if you are trying to write a cross-platform app. The biggest missing link for cross-platform desktop development in MAUI is Linux. (There's at least one open source fork working on a GtkSharp implementation/backend for Linux, but I don't know the ETA on that shipping.)

[ocdtrekkie]

IMHO, you only know a .NET platform is there to stay when they finally get around to adding VB support to it. WinForms? Solid. WPF? Here forever. UWP? Never going to go away.

.NET MAUI? Who the heck knows, it's still C# only.

[WorldMaker]

MAUI on Windows desktop is just a cross-platform wrapper around WinUI 3 (UWP's UI replacement) on top of WPF. Worst case, if you are building Windows Desktop apps, you eject back to WPF. [0] For the rest of the platforms you could switch to Avalonia or Uno perhaps.

[0] Though of course the question then is that if you are building WinUI 3 apps and don't need cross-platform why you don't just use WPF directly, and I don't have a good answer there. I think MAUI might be slightly more appealing if there was a stronger bridge from "start with a WPF app then expand it to MAUI". (You can do it, in some ways it is straightforward, but it's not an official garden path.)

(ETA: Though I get you on the VB.NET as gate idea. It's a big reason I still don't entirely trust Razor much less all the hype around Blazor. Blazor more than anything feels way too much "for people that missed Silverlight, here's a worse ASP.NET Core Silverlight" with shades of ASP Classic runat="server" full circle)

[ocdtrekkie]

The entire cross-platform path is extremely rocky. Let me give you an example:

My home automation system runs as a .NET Framework WinForms app written in VB. I'm interested in moving it into two directions: I would rather run it as a service, and I would like to be able to run it on Linux. VB .NET works on .NET Core in Linux environments, without a UI framework like MAUI, this should be trivial to accomplish both... right? RIGHT?

Visual Studio happily provides a .NET Framework template for building a Windows Service (for C# or VB), which my app could work under pretty easily. Or there's a Worker Service template which is cross-platform .NET Core (for C# or F# only... for no technical reason whatsoever, Microsoft just didn't want to bother)

The Windows Service template provides basically the scaffolding entry points for every way you interact with a Windows Service, you can pretty much just paste the code in for what happens when the service starts and stops. This is straightforward and easy and you can tell was designed by the same sort of people who came up with the WinForms editor: It's simple, it's obvious, and anyone can do it. I wrote my first practical Windows service one day, and it was done that day.

There's instructions for turning a Worker Service into a Windows Service here: https://docs.microsoft.com/en-us/dotnet/core/extensions/wind... I think it's safe to say, this is not simple or straightforward in any way (especially since "Rewrite the entire worker class" is a step here...

And that gets you back to... a Windows-only service? What the actual heck?

So here's what I am mind-boggled hasn't happened here: Microsoft should have a cross-platform service template (in all supported languages, please and thank you), and it should give you entry points for starting and stopping the service and such which are all pretty much the same between operating systems, and then it should handle the scaffolding to translate it to the appropriate OS out of the box.

[WorldMaker]

That's a very different can of worms. I've used third party libraries for Windows Services since forever because the .NET Framework templates were never great and Windows Services are a bad idea that are dumb to create and I think awful to maintain/manage.

At this point, personally, given the choice, I'd rather just create boring CLI applications that I can stick in cron jobs (or Windows Scheduled Tasks) than ever create another Windows Service if I can avoid it.

Given how dumb it is to create Windows Services and how dumb it is getting to create systemd-style services for Linux I can't possibly imagine how anyone could abstract that well cross-platform. That sounds like an awful minefield to create lowest common denominators that no one likes.

I think we already have such a cross-platform abstraction: it's classic CLI apps and whatever task runners you can find/stomach. .NET Core/.NET 5+ is great at cross-platform CLI apps.