[RESOLVED] Difference between Windows Forms App and Windows Forms App (Net)?

[FunkMonkey]

Hi,

I'm generating a new program, tried windows frame first time, but wondering what is the difference between Windows Forms App and Windows Forms App (Net)?

NEVER MIND, I found the answer. Thanks for reading.

[jmcilhinney]

For future reference, rather than editing your first post, add a new post and include the answer to your question, so that it might help others.

It's worth noting that your original question is wrong and actually indicates that things are opposite of what they actually are. When creating a new project, a number of templates have "(.NET Framework)" in the name. Those will create a project that targets .NET Framework, up to the last version that was 4.8.1. Those without that qualifier will create a project that targets .NET/.NET Core. Some years ago, Microsoft created .NET Core as an alternative to .NET Framework, providing most of the same benefits as well as some additional advantages. I'll let you do your own reading on what the actual differences are. .NET Core was at version 3.1 when Microsoft stopped new development on .NET Framework at version 4.8.1. There next release was .NET 5, which was touted as a merger of .NET Framework and .NET Core, although it was based on the .NET Core codebase. They considered .NET Core to have taken on all the good features of .NET Framework that it could so only one branch was required going forward. From that point on, targeting .NET (Core) was considered the default, so project templates that do so have no qualifier. Targeting .NET Framework is considered legacy, so project templates that do that are specifically qualified as doing so.

It's generally best to target .NET if you can, because all new development is being done there and .NET Framework will eventually fall out of support, but there are still certain advantages to .NET Framework for Windows Forms and WPF development. Neither of those was originally supposed to be supported by .NET Core but Microsoft eventually realised that the demand was too high and added them in .NET Core 3.0. There are still a few glitches though, especially in VB. Things like the My namespace and Application Framework in VB actually held up support being added to .NET Core and they still require a bit of jiggery pokery at times. Also, the designer was rebuilt from scratch and can have some issues around the edges too. There is still some new development being done in WinForms in .NET Though, e.g. a dark mode was added in .NET 9.

[squatman]

I've only just watched a video on the .NET 9/10 Dark Mode and Visual Styles, which intrigued my because Dark Mode has been requested for the application I manage so was going to be looking at a manual implementation. So I'm now considering .NET (Core) over .NET Framework for my new project. I'm also trying to weight up if it's worth learning WPF instead of sticking with WinForms. Mainly because I want to create a good UI that is fully DPI aware including images in buttons for example.

jmc, in your post above you mention WinForms and WPF have some glitches in .NET (Core), especially in VB. I work in VB.

Can I ask you for your suggestion/advice on the route I should take. The new project of mine will be quite large and around for a long time. I'm confident in VB .NET Framework (still tonnes to learn) and WinForms. Should I change now to prepare for the future?

• VB or C#
• WinForms or WPF
• .NET (Core) or .NET Framework

Thank you.

[jmcilhinney]

• VB or C#
• WinForms or WPF
• .NET (Core) or .NET Framework

To get the most out of .NET, it's a good idea to learn C#. That said, you can still create apps using WinForms and WPF perfectly well with VB. Don't learn C# unless you see some specific benefit.

If you're just creating a standard Windows UI then WinForms is fine. If you want something really polished with some customisation then learning WPF will be beneficial.

.NET Framework 4.8.1 will be supported for years to come. If you want to support .NET Core in other apps and libraries then I'd say go with .NET Core, as long as there aren't any specific roadblocks, e.g. there's no ReportViewer control for .NET Core. The glitches I mentioned are no more than annoyances that you can workaround fairly easily, if you encounter them at all.

[Shaggy Hiker]

I have used WPF in Core, and found no particular issues. WPF does come with a learning curve, as things behave differently, but you do get the features you are looking for. Overall, once I had a bit of experience with it, I found WPF to be easy enough to use, but not AS easy as WinForms. The ability to go good drag and drop of controls in WinForms means that it will always be easier to build forms in. With WPF, you have FAR more control of layout, but that isn't easy to achieve, so you have far more work to do, as well. It isn't difficult work, but when compared to the ease of visual form creation using drag and drop, it's undeniably more work.

I also wrestle with Core vs Framework. For any new work, I just use Core for everything. However, I also have a very large application based around plugins. That was written in Framework, and I have looked into what would be required to shift it to Core. There is no easy answer to that, in this case. There is the main program and around 30 dlls, most of which are dynamically loaded as plugins. One of the changes between Framework and Core is the mechanism used for dynamically exploring dlls, which means that I can't mix and match. Everything has to be Core or everything has to be Framework. Moving from Framework to Core would be super simple, as all those dlls are pretty standard fare and nothing about that would need to change (at least as far as I am aware), but it would still mean converting 30 projects over, and that would take a bit of time.

So, I would say that if you are starting a fresh project, might as well be Core. If you are working on a legacy project, stay with whatever it already is. WPF gives you all kinds of flexibility with layout, but it will take longer to craft each and every form. A simple messagebox that might take you a couple minutes in WinForms, will take you half an hour, or more, in WPF. And as for the language...I still prefer VB, but C# is more widely used.

[jmcilhinney]

If you are going to learn WPF, be sure to learn the MVVM design pattern from the outset. WPF can be used like WinForms, where you add a control to a window, handle an event and then do some work, but you're not getting the most out of it if you do that. You should be binding all your controls to a view model and then doing the work there. When the user makes a change in a control, that will update the bound view model and that's where and when you do work. You might update other view model properties and those changes will pe propagated back to the view (the window and its controls) via data binding again. Data binding exists in WinForms but is very rudimentary compared to WPF. Data binding is part of the WPF learning curve as it's very different to WinForms but, as Shaggy says, once you can do it, you can do it.