Replace ".NET" with "Windows" maybe?

AS a longtime original VB/Winforms developer - MS lost their mind on desktop development and didn't look back.

They chased EVERY fad that could be chased. Silverlight, UPF, XAML, WPF, Islands, MAUI. This is one of those things - imagine if they'd focused on building an amazing and cross platform (ultimately) toolkit with just a basic drag and drop designer? Who cares about "styling" your app and all the rest of the garbage.

How many lost years and peoplehours?

This has been their modus operandi forever.

I've got to the point where I don't trust them on any of this stuff. I target WinForms and if they ever decide to kill that then I'll abandon the platform completely.

>Who cares about "styling" your app and all the rest of the garbage.

One of the problems with WPF is the lack of styling of the standard controls. It takes a lot of work to ensure your app doesn't look like a turd.

I've been using MahApps.Metro[1] and MaterialDesignXAML[2]. Those two libraries have made me feel like sticking with WPF until I retire in 5 to 10 years. I'm constantly getting feedback from clients that the applications look so modern. It's been a nice selling point as my niche is rewriting VBA/VB6 engineering software.

[1]https://mahapps.com/

[2]http://materialdesigninxaml.net/

Same. WPF in an MVVM pattern is so comfortable to use once it clicks. It has its quirks but for everything there is a workaround once you stick to the pattern.

For the creators of Mahapps I have eternal gratitude.

Why would you want to style standard controls in a desktop app? They should look the way they look everywhere else in the OS.

Windows has multiple competing standards in the same OS, even from their own software distributed with the OS. It’s embarrassing.

Every once in a long while (very long now) you'll stumble across a dialog box that looks like it's from Windows 3.1. ODBC is one of them that's still that old.

It is, but there's still a standard system style that the majority of the apps are expected to use. Which is exactly what WPF uses - it's fairly easy to see if you take a WPF app and observe the differences on Win7/8/10.

In any case, surely, adding yet another different style only makes the problem worse.

Right now if i open a Sysinternals app I’ll have the text in the UI rendered in one way and the title bar rendered in another. It’s jarring.

Not to mention they behave differently with respect to HiDPI.

Remember how much criticism Linux and other unixes got by people complaining about apps created with KDE on Gnome desktops and vice versa?

I'll never forget ;-)

And that’s a disaster too.

Really the only one that’s done it correctly is Apple.

Apple also did this whole "our apps are special" thing more than once.

I don't know why, but there's this weird temptation for every app to try to present itself as some kind of unique work of art, when it comes to UX. But I don't want art, and I don't want branding. I just want ergonomic tools - and part of ergonomics is not to have to re-learn everything every time you pick up a new thing.

Nobody mention the gui toolkits for Java or desktop window managers for Linux…

WPF has no such concept. Even if you don’t use a library for this, it’ll then just use the built in style after detecting your OS version and adapting to that. But it does this by pulling out hard coded resources shipping with WPF. If you wish, you can override and tell WPF to look like XP on Windows 10 instead… It’s all just a good try, but still a facade. It does not and can not (per design) rely on “native controls”. I suppose because it’s DirectX based rather than GDI.

Not only lost productivity, but getting executive buy in to invest in WPF was difficult after Silverlight.

Kinda joking, kinda serious, but all the Microsoft UI changes in the last 10-15 years have definitely helped enterprise IT adopt internal web applications. :)

Very true. I used to be a desktop dev but since Windows 8 MS has convinced me it’s better to do web stuff.

It’s fun to think that, after all these years, we are back to screen-oriented terminals (browsers) accessing mainframes (cloud apps)…

I loved the 3278.

And now we write “screen scrapers” to get information from html instead of the terminal emulators. Rinse. Repeat.

<sarcasm> True. Frameworks to build web applications only come out every few months.

IMO they need to realize the common denominator of all these failed and deprecated frameworks is the very thing they've desperately clung onto over all these false starts... and that is XAML.

Get rid of it.

XAML is good. It's very easy to build interface by nesting components then styling it if needed, and doing data binding. All the web alternatives are harder to use and came 10-20 years later.

XAML is why I’ll never write a Desktop App with .NET, who’s been unable to rid themselves from it.

React, Vue, Svelte as well as Flutter & SwiftUI all implement different but vastly more productive reactive dev models.

MAUI will not be resurrecting .NET Desktop Apps which have been on decline since WPF. Blazor Desktop Apps might, anything XAML won’t.

XAML is the only thing I was ever able to write a complex layout in, run the app, and see it look exactly as what I intended on the first attempt. That would meet my definition of productivity.

For example, my experience with CSS has been the opposite of that. F5 a million times before the layout works the way I want it to. Sometimes even googling how to do create some type of layout because I can't think of it on my own.

XAML is good for structure, same way HTML is. But by god is styling it a major PITA of boilerplate nesting hell

>"They chased EVERY fad that could be chased. Silverlight, UPF, XAML, WPF, Islands, MAUI"

Being a wise man I spared myself from this madness long time ago;) When I need Windows Desktop App I use Delphi or lately Lazarus that can do both Windows and Linux GUI from a single source and produce native standalone executables.

WinForms is still around, and works as well as it always did. That or WPF are still the sanest choices for desktop apps in .NET, IMO, so long as you're only targeting Windows. And WinForms specifically resembles VCL a lot.

I skipped .NET bandwagon for desktop completely. Comparatively to Delphi there were exactly zero business reasons for me to move my code or use .NET for new apps.

On a technical side there were no gains and numerous limitations.

On the technical side, the biggest productivity gain is from having a garbage collector. Beyond that, language features: while C# 1.0 started in a spot very similar to Delphi (+GC), it evolved much faster - e.g. getting generics in 2005.

But, yes, if you looked at it in 1.x days, it really looked a lot like Delphi libraries with Java-like syntax. So if you were already using Delphi, there wasn't much point.

>"On the technical side, the biggest productivity gain is from having a garbage collector."

1) I use leak detection tool so no productivity gain in that area. Besides it is burned into my brain to always write deallocation code first before doing any allocations. That is when my classes are not using interfaces that are reference counted. In reality I could hardly remember any instances when memory / resource leak tool showed any. Also I did not have to dance around IDisposable, Weak and object caches shenanigans.

2) Generics - this is great feature but in my opinion it is mostly geared towards libraries writers. Being more of a product / application oriented bar few exceptions I personally do not use it much neither in C++ nor in Delphi (Delphi has generics since 2009).

> 1) I use leak detection tool so no productivity gain in that area.

These are never as good as garbage collection. In some cases, not even close.

I consider this statement false

Consider it false all you like, the proof is in the pudding:

https://www.forbes.com/sites/gordonkelly/2021/11/16/google-c...

And the crazy thing is that all these frameworks were basically incompatible variations of the same thing. Since WPF nothing has really gotten better. Just different for no good reason.

I will never bet on any new MS desktop development framework anymore . It’s either WPF or preferably web (even Electron) for me.

To be fair to UWP XAML, it's more efficient than WPF.

I don't mean because it's written in C++ instead of C#. The render pipeline of WinUI is more efficient. It's really interesting, but unfortunately I can't find the technical blog I was thinking on.

It’s more efficient but much less reliable. Like if you change from light to dark mode, there’s a 20% chance all UWP apps that are open crash.

And as efficient as it is, it still can’t resize windows without flickering. It’s worse than WPF or Win32. And there still aren’t proper APIs for configuring the titlebar area.

I wish they focused on getting their vendor partners to make efficient processors, rather than try to get all windows developers to rebuild software to run on hobbled ARM hardware.

That doesn’t explain why they had to roll a new framework instead of improving WPF. It may have been ok if they provided an upgrade path but since Winforms they haven’t bothered with that either.

Politcs, driven by the same group that botched Longhorn in name of C++ and COM.

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

> Replace ".NET" with "Windows" maybe?

There's Uno, Avalonia, Xamarin Forms, and MAUI, all cross-platform. I think it's a mess no matter what.

In all fairness, at one point you could actually make sense of things.

Unless I'm misremembering, until recently Avalonia was still being touted as primarily a replacement for Desktop WPF. I was shocked to see they're talking about mobile now too. I guess it's somewhat expected.

Uno basically does what MAUI does. The main difference being, Uno has been around for a while longer and something you've been able to use for some time. I'm pretty sure they had usable versions for well over a year before MAUI was even announced.

In any case...

Microsoft's UI story is a non-starter until they get back to the point that a user can:

- Click new project - Fill out the form - Get a Design window, - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window, - Double click on the button, get taken into a generated event handler, and the user can intuitively put in the right code (i.e. updating the viewmodel with 'hello world'.) - Click 'run'

That's the Story that got an untold number of new developers -enamored- with VB6, a language that got so entrenched Microsoft had a hard time killing it. It brought a number of developers into the world of C#, making it easy for to write applications used at work that a whole team could use. That's actually how I 'eased' into programming at my first workplace; I wrote an app with a big ugly panel and a bunch of big buttons with labels that would automate tasks. Need a variation on a theme? Drag a new button over, maybe do some light refactoring, test, publish, tell the guys to restart the app. 10-15 minutes tops.

Sure, Eventually I had to go through a spaghetti mess of callbacks and crappy generated code, but it was good refactoring practice ;). And when I left the company, someone else took over the code and now they are a software developer too.

And you could really evolve it. Databinding was surprisingly good and easy and fast - still beats web in my view - autocomplete, panels / options groups / tabbed windows etc all worked well (and were fast).

> Microsoft's UI story is a non-starter until they get back to the point that a user can:

Why do you care about this stuff? I don't understand. Surely most developers can build a simple app with a few buttons easily in whichever framework they're using. This stuff doesn't really matter for I'd dare to say 90% of developers. What matters is how hard it is to build and maintain complicated stuff. And there WPF blew WinForms (and VB6) out of the water.

Not sure why you think how difficult it is to put a couple buttons on a page and make them do something would have any effect on the success of a UI framework. That's literally not even a consideration when we make decisions on what to use for a project.

If WPF ran on other platforms, we would use it for everything. We use Avalonia instead, and it's pretty great.

But there are 2 basic types of multiplatform UI frameworks - the ones that wrap native controls and look like most other apps on the platform, and the ones that do their own rendering and look the same on every platform. Avalonia is in the second group, so if the former is a hard requirement then it is not a good choice.

> What matters is how hard it is to build and maintain complicated stuff.

What matters is how hard it is to deliver a product to the end users. As I gave in my personal user story, yeah, I had to eventually pay the piper and refactor significantly to make sure things were maintainable. But it was a good lesson learned, and I've met many other developers over the years who got hooked on C# in a similar way.

> And there WPF blew WinForms (and VB6) out of the water.

WPF would be fine for this scenario. If we could do things like this at a WPF level of designer I'd be happy. It's got a little more of a cognitive load to get started but long term is easier to reason about long term and from a conceptual standpoint is more transferable to other contexts (i.e. Web MVVM Frameworks.)

I haven't looked at Avalonia in it's current state (last time I gave it a peek, it was still in a 'almost-ready' status) but if they really are able to do multiplatform as I see they say now then perhaps that's what I'm saying is needed. (Which may be more of a statement on the state of Real OSS Awareness in the .NET community.)

Definitely will give it a go, since I know it's supposed to be a replacement for WPF so I'm hoping(?) that the existing tooling out there is usable

> - Click new project - Fill out the form - Get a Design window - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window

Non-starter these days. Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here. Unless you have some novel idea for how to design graphically for all sorts of screen sizes.

> Non-starter these days.

It's about the species; Remember that I mentioned that in the context of 'someone getting started'. I say what I say because it would be the best thing to help new users get 'hooked,' not necessarily because it's the best way to make a maintainable app. (IDK though, some of my one-team winforms stuff was actively maintained for years after I left)

> Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here.

There's no reason you couldn't handle such a thing in WPF. Sure, it may be more -work- to check representation in both formats, and some form of helper (that would handle certain scaling factors of buttons/etc) would be a boon to developers. That's not the way I look at it though, see below;

> Unless you have some novel idea for how to design graphically for all sorts of screen sizes.

It's not necessarily about making a 'single' UI that works on both mobile and Desktop. If you can even get to the point where a user can make separate Mobile -and- Desktop 'form-style' built screens for their app, all in one happy framework/language... Frankly that would be the best thing overall, since you can provide optimized Desktop -and- Mobile UIs, and not have to have a bunch of disparate technologies used to build each.

I personally think it's a mistake that frameworks try to be all in one by trying to target mobile (phones and tablets), desktops, and even web. It just doesn't work, and I don't know of a single platform that actually accomplishes it without major limitations on one or more platforms.

> - Click new project - Fill out the form - Get a Design window, - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window, - Double click on the button, get taken into a generated event handler, and the user can intuitively put in the right code (i.e. updating the viewmodel with 'hello world'.) - Click 'run'

Its been a while since I looked at these and I was having a look for a designer like WPF for Win UI/Uno etc - does this not exist?

When I played with Uno, There was a UWP designer (At the time Uno relied on UWP for the API/Translation, IDK if that's changed.) It worked mostly like the WPF designer but I think it was slightly more limited.

Also if you still need to support XP (even back when it was still getting patches), forget it, Microsoft has no interest in supporting you.

Even if you want to use the latest and greatest UI, your customers need to keep up too. Completely unworkable.

XP is 20 years old, its older than invasion of Afganistan.

I recently ran XP in a VM inside Windows 10 and was amazed at how much faster everything ran, how quickly programs start, and how responsive they are. Feels like we lost something along the way...

WPF compiling to WebAssembly would be ideal.

are you still doing desktop work? if so, what are you using?

I actually moved away from desktop.

Lightweight web apps mostly in python (Flask).

Slack apps / bots with a bunch of commands (backend does lookups, generates PDFs)

People don't fully realize what we gave up dumping desktop development, you used to be able to build our nice biz specific crud apps (customers, projects, scheduling etc) using a bunch of tools. These things were usually darn fast if you were careful and you could make them very keyboard driven (ie, put the keyboard shortcuts on button labels etc).

My strategy for dealing with Microsoft's regrettable desktop GUI roadmap is to use the web as much as possible. .NET has an incredible suite of features for pushing functionality to the browser. Kestrel is one of the fastest web servers available today. Developing directly against the AspNetCore pipeline has a bit of a learning curve, but it becomes very intuitive once you get over the DI/startup hard bits, and the performance you can get with low level middleware is staggering (to me).

There are very few applications that simply cannot work in a web browser in 2021. Even accounting for all the inconsistent bullshit between browser vendors, you can still arrive at something that works as far back as IE6 if you are conservative with your footprint.

Do you really need flexbox, webgl2 and GPS navigation for that warehouse inventory management application? Does everything have to live the various app stores? Will your users revolt if there isn't some ceremonial download & install phase of using your product?

I would go so far as to argue for deployment of a self-contained webservice to the end users that could be accessed via any arbitrary localhost browser before succumbing to the Microsoft Desktop GUI framework du jour.

"I would go so far as to argue for deployment of a self-contained webservice to the end users that could be accessed via any arbitrary localhost browser"

Might as well use Unity game engine and write your app inside one.

There seems to be some people writing UI applications with the Godot game engine. Given the dismal state of desktop UI frameworks/tools, this seem to make more and more sense (very light binaries, solid cross-platform support, a WYSIWYG toolkit with good scripting functionality, a high-performance 2D renderer, access to C/C++ if you wan to go low-level, you name it.)

Examples:

https://www.wonderdraft.net/

https://github.com/Orama-Interactive/Pixelorama

This is an accessibility nightmare. Please think hard before doing this.

Well, the two applications I’ve linked above are very graphically intensive (the first one is a map designer, and the second is an image editor), up to the point that it will be meaningless to add any screen reader or dictation support. In some cases you’ve got to admit that it’s close to impossible to bring certain features to people with certain disabilities (although I think this should be its own field of HCI research, maybe it can be possible someday?)

For "regrettable" substitute "tire fire"

Instead of chasing the next Microsoft fad, I've decided to try AvaloniaUI for my next graphical app.

It looks mature enough now, and has a better chance of being still useful in 5 years from now than WinUI or MAUI or whatever is the latest GUI tech MS wants us to use.

It still has some rough edges, but I really like it since it seems to be only .NET GUI choice compatible with Linux. I'm bit sad that MS might suffocate the project with the Multi-platform App UI (MAUI) which does not work on Linux :/ Fortunately, MAUI seems to have much more glitches than Avalonia ATM

Since MAUI works on Android, I assume MAUI will eventually support Linux.

Same here, I least I know this will consistent across platforms.

Note that Maui is the name used by an older ui toolkit https://mauikit.org/ and you probably should refer the one by Microsoft to .Net MAUI to avoid confusion.

They just keep recognizing that WinForms is the best. And you can still use it

Do they have full support in .net 6? I believe in previous version it was a partial/beta implementation. Hardly any mention of winform in the announcement.

I am basically stuck on .net 4.8 because of that.

I just ported a WPF app where the story is similar. Yes, I'd call it "full support". It's not a drop-in replacement, though, except for really simple apps. Check the Breaking Changes List for .NET 6[0], .NET 5, and .NET Core 3.1. Some more niche APIs like `System.Runtime.InteropServices.RegistrationServices` are not supported on .NET 5+ at all. If you have NuGet packages that haven't been updated since 2011 you may need to find modern replacements. There is an Upgrade Assistant tool[1] which can do much of the work. You'll probably have to spend a few annoying hours googling and editing .csproj files by hand.

[0]: https://docs.microsoft.com/en-us/dotnet/core/compatibility/6... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/upgrade...

WinForms support in .NET 5 and 6 is great. It's getting a lot more attention than WPF (which is owned by the Windows team), and it's likely that in .NET 7 it will be trimmable and maybe even AOT-compatible.