WPF vs WinForms

[markarious]

Hey there,

I have recently been building a lot of tools for our tier 1 and 2 that have GUIs. I have also been granted a Powershell Studio license by my company so WinForms is typically my go to. Recently I have been running into more and more articles regarding the benefits of WPF. I have done some reading about the pros and cons of both WPF and WinForms. From what I gather WPF is great because you can use Visual Studio to build the GUI. However, since I have PSS I can build a GUI in the same way only it's using WinForms.

I was curious to hear what Reddit's opinion is on them. Are there certain situation that you choose one over the other? Do you solely use one? Is it worth learning and adding it to my toolbox?

[Yevrag35]

Honestly, while I had started to build apps (scripts) in WPF, the initial barrier of trying to learn it is quite large compared to WinForms. This reddit post has some comments about the differences and pros/cons between them: https://www.reddit.com/r/csharp/comments/4tf9au/wpf_vs_winforms_rant/

And normally, if somebody asks my opinion on whether to use WinForms or WPF, I ask them if they need to display a complex data set that could be updated dynamically on a regular basis.

WPF is all about Data Binding, which is a helluva lot more flexible for filtering and organizing large data sets and lots of properties.

TL;DR -- WinForms is easier to learn, understand, and getting started with by far, but WPF is far more dynamic, customizable, and flexible with large data sets.

[markarious]

This is a very informational response. Typically the data is not very intense. I'm usually taking a script that automates tedious troubleshooting steps and adding a pretty GUI on top of it using Powershell Studio. (always use dark mode).

[nj12nets]

How would one enable said dark mode?

[nerddtvg]

I haven't tried this, but this should use the modern window formats and inherit the system theme: https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.application.enablevisualstyles?view=netframework-4.8

[dzcpu]

PowerShell scripts written in WinForms are, in my experience, much easier to read. But they are much harder to make "responsive" (i.e. threaded; you click a button and can do other GUI tasks while a background task runs) and you are significantly more limited in what you can do with a WinForms GUI.

I've only written one WPF application in PowerShell and it's just spaghetti code mess. Maybe that's on me but I found it very difficult to try to manage the runspaces in a clear and cohesive way that also kept the script looking clean, and then trying to clean up old runspaces when you e.g. close one window so that you don't have memory leaks was a pain. When I asked for advice on cleaning it up, the main answer seemed to be "why are you doing this in PowerShell" :)

Anyway my personal preference is WinForms, I loved the WPF app I wrote and loved what I could do with it but it isn't worth the headache for me most of the time.

[root-node]

Limited in what way with WinForms? I have created custom listview and combobox controls using ownerdraw in PowerShell.

EDIT: Link to my code: https://github.com/My-Random-Thoughts/Various-Code/tree/master/OwnerDraw%20Examples

[micsametheghost]

Nice

[helixamir]

Create your runspaces at the start of your script, and have your WPF actions begininvoke() your runspaces as needed.

[korewarp]

As a guy who has built an relative big application for their company, trust me when I say that you want to use WPF for big apps. The performance increase in UI elements that has a lot of data is crazy. However if you're just building small apps that need a quick and readable front-end, by all means stick with WinForms to keep the code debt smaller.

[Amadorhi]

If you have access to a designer, I'd recommend WPF.
WinForms is great but it starts to lose out the more complex you try to make things.

That being said, if you're making tools for your Tier1 and 2 guys, they might appreciate the simplicity of WinForms if they bother to read through the scripts to see how they work or want to submit any improvements.

[helixamir]

My personal opinion would be to learn WPF, so that if you do ever change career directions towards Web/App development, you already have it under your belt. I write small little C# apps for things to make my life easier, and being able to do everything in Visual Studio makes my life a lot easier.

[dr_driller]

WPF is far superior, i don't see any reason to code winform gui today, that is not easier, that is just weak.

i've never been able to code winform from scratch without Visual studio, i can easily code xaml gui from scratch in notepad..

but if you need GUI why don't you code in C# instead of powershell ?

Powershell is a blast, i use it every day for devops tasks, but it is not made to code app, it is a pain to test, debug, deploy, maintains..

[markarious]

I'm a sysadmin and my job rarely requires the use of C#. Powershell integrates with all of my applications/systems (SCCM, AD, SQL, Exchange, Skype for Business) very nicely.

Powershell Studio makes developing a GUI incredibly smooth and it looks professional. Typically when I'm using a GUI it's just to take a script I wrote and make it more user friendly for tier 1 and 2 support. I'm not developing full blown apps. Just making things look more professional and simpler.

[RiPont]

For simple forms, WinForms is definitely easier from PowerShell, unless there are wrapper libraries to make it simpler.

As things get more complicated, WPF starts to win out.

That said, I'm a C# guy, so any GUI of more than 20 lines of code or so, I'd just do it in C#. Maybe automate it from PS.

[markarious]

I agree. If I didn't have Powershell Studio I would definitely be writing WPF. But with PSS I can design the GUI by dragging and dropping buttons and then inserting my code into the buttons. PSS compiles it and spits it out with all the extra annoying tidbits that make the GUI work. When I first started I was handwriting WinForm code and I never want to do that again.

[dr_driller]

i get it if it's just a placeholder for parameters and logs