Depending on your age and experience as a .NET developer, you might or might not be familiar with the technology known as Windows Forms. Windows Forms, or WinForms, was introduced together with .NET 1.0 in 2002. It was the first desktop UI technology for .NET.
We’re now 16 (!) years later, and WinForms runs on the latest version of the .NET Framework (currently 4.7.2) and .NET Core (currently 2.1). But because it’s so old, has been succeeded by WPF and UWP, and only runs on Windows, many assume WinForms is dead.
And while it certainly has some wrinkles on its face, it’s not just dead yet.
Don’t believe me? Keep reading.
A Brief History of WinForms
As I mentioned, WinForms was introduced together with the first version of the .NET Framework in 2002.
Don’t underestimate how different these times were.
Download a free trial of CodeIt.Right and get instant, specific code reviews that help you get it right, whether you use Winforms, WPF, or anything else.
A Snapshot of the World When Winforms Was Born
The first iPod had only been released four months earlier, and Microsoft Windows was still the platform of choice for basically everybody. Speaking of Windows, Windows XP had also just been released.
The internet was already quite prevalent, depending on where you lived, but it wasn’t the internet we know now. Techniques like AJAX existed, but were very rare (in part because it would take another four years for jQuery to be released). The desktop was still where it all happened.
And the desktop, that was Windows.
WinForms provided .NET developers a familiar way of writing user interfaces, as WinForms was a layer above the Win32 API. You could write both the underlying code and the UI in the same .NET language, C# and VB.NET being the most popular ones.
The introduction of .NET also saw the release of an IDE: Visual Studio. Visual Studio included a drag-and-drop UI designer for WinForms. This greatly improved the productivity of developers, even if they weren’t UI experts.
WPF and the Aging of Winforms
WinForms received several improvements?in subsequent versions of the .NET Framework. But in 2006, Microsoft introduced .NET 3.0, which included the Windows Presentation Foundation or WPF. WPF took a different approach.
WPF separated the behavior of a user interface control from the way it looked. At the time, this was revolutionary and it gave us the possibility to do crazy things, even if they weren’t always very usable. WPF also brought us XAML, i.e. the Extensible Application Markup Language.
The combination of a .NET language (e.g. C# or VB.NET) for logic and XAML for markup continued in Windows 8 and Windows 10. The latest desktop UI framework from Microsoft, the Universal Windows Platform or UWP, is based on XAML.
So has Microsoft moved on after WinForms? After all, they have released several other desktop UI frameworks, and WinForms is a staggering 16 years old! The answer is more complex than just yes or no.
The Current State of WinForms
Because WinForms has been around for so long, it is a very mature platform that integrates into Windows very well. WinForms applications could be written years ago and still run fine on Windows 10.
Also, don?t underestimate how many companies still have WinForms applications that are important to their daily operations. You could do worse than to specialize in maintaining, improving or porting these applications.
Another important fact is that Microsoft hasn?t stopped support for WinForms. While there are no major new developments planned for WinForms, they will keep releasing bugfixes. These ?bugfixes? include things like improvements for high DPI monitors in .NET Framework 4.8.
.NET Framework 4.8 is the last version of the ?old? framework. But you will also be able to run your WinForms apps on .NET Core 3!
Even the next version of .NET, Version 5, will support WinForms, allowing you to use the new API?s that Microsoft will introduce as part of .NET 5.
And it?s now all in the open. Windows Forms has been open sourced and the roadmap is there too.
This doesn?t sound like a platform that is completely dead.
Where WinForms Is Still Useful
You might think this situation is comparable with the many COBOL applications running out there. They are making money, in need of maintenance and updates, but not something for creating new applications.
But there is something WinForms does better than WPF or UWP: ease of development.
WinForms is great for making a quick prototype of an application. The learning curve is a lot less steep than it is for WPF or UWP.
The UI editor in Visual Studio is much better. No need to struggle with the often complex syntax of XAML, just drag and drop your controls and wire it up to your code.
For WinForms apps that run on .NET Core, the designer is currently missing for Visual Studio 2019, but there is a workaround. And the team is working on a real solution.
If you want to focus as little as possible on your UI code, WinForms is actually a better choice than WPF or UWP. WinForms allows you to focus on your business logic, and spend less time developing your UI.
But It’s Almost Dead, Right?
You never really know which direction the technology world is going to take. WinForms has been able to stay around for a very long time, longer than most web UI frameworks can dare to dream about.
I think we could even say that WinForms can still be relevant for desktop applications on the PC, it’s just that the PC desktop has lost a lot of its relevancy.
We might spend a lot of time working on our desktop, but we only use a handful of desktop applications: mainly office applications and a browser. And we spend most of our time in the browser.
I’m even writing this in a browser, instead of a desktop text editor. This sounds normal now, but it hasn’t always been so.
So if you’re starting a new app that will be around for a while, your best choices are probably Xamarin or the web. This depends on how familiar you are with these technologies, but they are currently the most future proof and they run on more than one platform.
But to say that WinForms is dead is a bridge too far. WinForms applications continue to run on thousands of PC’s, and these applications will need to be maintained and improved upon for the coming years.
Learn more how CodeIt.Right can identify technical debt, document it and gradually improve the legacy code.
WinForms as it is known now may have been introduced with .NET 1.0 but was really in existence before that in Visual Basic at least as far back as VB4. How WinForms works in terms of form painting, generation of stub methods you complete, etc. is functionally much the same as it was in pre-.NET Visual Basic.
Thanks for that! I didn’t realize that (I have no experience with pre-.net VB). Good to know.
I just did a very small, quick app in WinForms to do one little task, which has got me surfing around randomly reading about WinForms and it remains super speedy for creating an interface, and the way it does it goes all the way back to Visual Basic 1.0, not 4.0. It was revolutionary back then to be able to just drag and drop controls onto a form and “wire them up”. All on 16 bit Windows.
I wrote a lot of stuff in VB3 and the main disadvantage was that once you wanted to do more advanced stuff, you were typing in long, tedious API calls a lot of the time, which .NET improved on massively.
But anyway, Visual Basic invented the drag and drop IDE forms designer in its very first release.
Very interesting post and it makes me think that as usual, the best way to proceed with IT is to acquire solid background and fundamental concepts and then switch in an oportunistic way to the “dish of the day” required for living, paying the bills or just having fun. By the way, Visual Studio was already coined before .Net as I remember having worked with Visual Studio 6.0 (Aspen) to develop programs on both Visual Basic and C++. The IDE was slightly different from the .Net one but the basic windows and components were already there.
Yeah, while I was writing the article, I realized Visual Studio was a continuation of a previous product, altered for .net. I believe it was named Visual Studio .NET then? Anyway, I left it out of the article initially, and then no longer thought about it. Thanks for mentioning it!
I’d argue that WFP is ‘deader’ than WinForms.
Wpf was Microsoft’s attempt to give the world something new but it hasn’t taken off.
Wpf is a messy interface & doesn’t really offer anything more than Winforms.
Thankfully there are some beautiful 3rd party control suites out there (devexpress, telerik, etc.) which allow the Winform lovers to reach the new heights wpf was meant to, without the mess of wpf.
Winforms forever! 😉
give me a break, all you anti WPF clowns have been proved wrong again and again, forms is for basic UI , even simple dynamic UI or styling creates a huge mess, after years of FUd from clowns like sinofski and hanselmuppet it’s still head and shoulders better than any alternative, is it too hard for the weaker devs, yeah, do WPF make > 100,000$ US, do WPF devs blog, no they do there jobs and leave the blogging to the Metro/Store/ Modern/Forms/Xamarin/WP/WM/Core shills, period.
Your post is about as coherent as WPF project.
All said and done, WinForms, and even MFC are still around, running on hundreds of thousands of PCs and continue to be updated, though no one talks about it. These days, everyone jumps on the latest new shiny thing. Silverlight? Adobe Air? Choose wisely.
You can easy estimate qualification of people by asking about WinForms: if they think it’s “dead”, they are dilettantes. WinForms has simple architecture, it’s FAST (compare to WPF & UWP) and has best integration with Windows internals. I always have dilemma what to use for Client UI, because I don’t want to be caught in the middle of project “this WPF sh***t slow like a hell”.
And I’m sure WPF – this is the first corpse on IT way! Overbloated, overengineered technology with stupid developers – they have no idea of consequences when they introduce things like Dependency Property – they have “BASIC” mind, which doesn’t care about performance. Well, many things in WPF is doubtful. We really need declarative UI, but not from MS dilettantes.
You probably hate UWP but I love it as it’s like Microsoft fixed all the crap in WPF and future proofed it by making it non-dependent on Win32.
If you’re about to create a new application and deciding between WinForms and WPF – start with WinForms. If you then need the functionality of WPF you can just add it in! Create a new WinForm, place an ElementHost control onto that WinForm, and then add a WPF form into the ElementHost control. Caveat – I haven’t done this but it’s easy to find instructions.
Now – you’ve got the best of both worlds!
your lack of skills in Dev and grammar say enough, your right to fear WPF, what a clown
Oh, the irony.
I’m here in the end of August 2019. It seems like WPF is more dead than Winform at this point???
So the question is, are there places where it is the right decision to do new applications in WinForms? What about in an enterprise where they already have a dependency on Windows? Where they don’t need the new shiny UI, but they need quick business applications to improve productivity. Now that Microsoft is supporting in in Core 3.0, maybe there is no better choice than WinForms!
To me, the fact that Win32 is on the chopping block means that WinForms is a non-starter. When (and I do mean WHEN) Microsoft cuts bait with Win32 (it has to do this due to legacy security issues) then you don’t want your organization to be stuck on an old version of Windows forever because of a LoB app that has to be re-written to allow you to move on. There are still tons of businesses stuck on Windows 7 because of the lack of foresight when locking into IE 10. Windows 7 IS being put to pasture, and those business will need to get off of it sooner rather than later.
Having said that, UWP is a great choice for LoB apps. Updates are automatic through a corporate Windows Store (yes, Microsoft provides such a service) and UWP is simply going to continue to grow and get better. 3rd party platform tool makers have embraced UWP and their WinForms and WPF products are moving to “legacy” phase support.
UWP, ROFL, you have no clue what your talking about
In corporate UWP is not an option.
My team have switched few years ago to WPF for LOB because it is technologically more advanced.
However it appeared that people on desktop likes traditional apps more. Also with WPF we have irritating issue: no true modal window. So we are considering to switch back to WinForms.
Ideally we would use WPF inside but looking like Winforms. Unfortunately classic theme is not sufficient.
Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API. People out there will hang on to what they know forever, not everyone, but many. I keep teaching myself Web API, .NET Core, React/Redux and Razer pages, but a lot of people just love their web forms.
I think I’ll plan on using WinForms for what I develop for Windows desktops for our internal company software and that’s probably where it’s used a lot. I think the advice given about if developing a new app really only applies outside of that environment.
What will you do when WinForms as a technology is no longer supported in Windows? Microsoft has been non-too-subtle about the fact that Win32 is going away sooner than we think.
Part of that rhetoric was just another way of marketing UWP.
Also, I do not believe Win32 going away is some kind of death for WinForms anyway. It may be that certain portions (GDI+) disappear. Most development (in WinForms) does not directly use GDI+ or many other deprecated Win32-specific features anyway. Even if it does not already exist, $$$ will drive a swap-in replacement for these deprecated dependencies.
Additionally, the bigger part of Win32 going away is simply Win64 taking its place. While it is true there are deprecations, What I think we’ve seen is Microsoft try to take a bite of the ‘golden Apple’ by making their own. They would’ve very much liked to kill WinAPI and shove UWP on everyone everywhere so they could have the same for themselves. This largely failed and the last couple of years you can see they have started to shift course. I think Microsoft knows this if you look a bit at their shift in stance on open source and even control of their own code bases.
What Daniel Przybylski mentions in the comments here is actually more the general direction I see things maybe reamping up a bit in the not-so-distant future. Maybe not Winforms specifically, but that will happen too. Maybe it’s largely some completely new UI desktop tech (docker?).
There is just a ton of value in combining the old with new. It’s the best of both worlds where it makes sense. Not only do you avoid complication/obfuscation and the security issues brought on with a host of technologies which are essentially designed to make protocols and the browser do things they were never intended to do, but also, you get the benefits of modern stuff like web and database services in the cloud.
I don’t disagree with a lot of what you said. I believe that Microsoft is going to draw a line in the sand and say “no more new Win32” and expel all of the Win32 from Windows at that point in time. I believe Microsoft may supply Win32 as Nuget packages, and thus ease the transition. The problem isn’t WinForms or WPF, the problem is that most of the LoB stuff in manufacturing is using direct Win32 API calls that are outside of .Net. Now, if Microsoft would encapsule the functionality of Win32 into managed assemblies, then I agree that WinForms and WPF could have a future in a world where Win32 no longer exists. I believe that this could be done because of .Net Standard. Existing WinForms apps that call Win32 would need to be updated to use the new assemblies and drop the unmanaged API calls. The method signatures and structs could all remain the exact same, but the underlying technology would be UWP.
And for the record, my original reply in this article’s comments was referring to writing new apps with WinForms. This time next year, if you’re still on an OS older than Windows 10 or Windows Server 2016, then you’re on a path to doom (IMHO).
“…Win32 is going away sooner than we think.”?
I’ve been writing Software for industry and commerce since DOS-times. As Windows 3 came to market I was asked where the future of operating systems will lead. I was convinced, Windows will predominate and evolve: I was right. And I started using the 16-bit Api and – under Window 3.11 – multitasking using Micro Focus Cobol!
What has this to do with Win32? I think a lot: Industrial systems are not conceived like a short-living App; they are made to last over many years using industrial standard interfaces.
I still have customers that use Windows 95! Don’t ask me where they get the compatible parts.
But this said, The Win32 Api is needed to run almost all professional programs written for PC application under Windows. This Api first delivered with Win95 has been developed and grown, but, the interface has never changed.
Programs I have written over 20 years ago still run on Windows 10.
Now you ask: “What will you do when WinForms (or Win32) as a technology is no longer supported in Windows”?
With Win32 going away, they’ll kill a great part of our industry! I’m not talking about ‘cool Apps’ running on clouds in the web. A lot of real work systems still rely on Windows XP because compatible drivers for later versions don’t exist. And we’re talking about systems, that would take many Millions to replace.
If “sooner than we think” is, say, 20-30 years from now. I’m with you.
I’m not saying that you’re going to find every single app ported to another platform. If people are willing to run Windows95, or even XP on old hardware because they don’t want to move, then so be it. I sure hope these machines never see the internet! Win16 has gone the way of the Dodo, forced by Microsoft in the move to 64-bit. There’s nothing stopping anyone from running WINE or some other Win32 replacement to keep these old apps going, but if Microsoft gets rid of Win32 like it’s promising to do (Windows 10 S is just the beginning). DotNet Standard is paving the way for Microsoft to completely separate itself from Win32. And remember, Win32 is not Windows. Win32 is a platform that many things Windows are built on, but the modern stuff is all based on the new Unified Windows Platform (not Apps, but the actual underpinnings which include all of the root Operating System stuff in Windows 10). Each feature ported to UWP is another nail in the coffin of Win32. Microsoft is writing a new Explorer shell to replace the Win32 version. The march away from Win32 isn’t going to take 20-30 years.
It’s not just ‘porting an App’ to another environment or being unwilling to move to newer Hardware. They would, if the costs were reasonable.
Companies like Breweries, Steelmakers, Car-builders and so on think in long terms. The equipment they buy and invest in is required to run over many years. I.e. a simple weighing device running legal measurements according to OIML is a relatively small investment of several 1000$. These devices go a long way from development to approval: The interfaces and protocols may be ‘out of use’ like RS232 in the world of play ‘Apps’.
Efficiency, Reliability and Durability are the key words in real businesses. Why do you think a company like Porsche uses COBOL as THE programming language for its sensitive operational Software (as well as governments, banks, insurances and don’t forget Military). These won’t place their data in the Cloud or rely on a Cool New Language which may be dead and gone in a couple of years.
The ‘once dead’ Mainframes are going stronger than ever, but, on the front end, PC’s are still needed to feed them. And with them, a reliable, scalable operating system – like Windows.
Where is the sense in ‘commiting suicide’ by trying to force customers into huge investments to replace their existing software to fit into ‘new’ systems? And should Microsoft try to force them, why should customers stay with the expensive licensing? They can just as well write their new Programs for other systems like Linux.
I started developing with WPF. Now I have to learn WinForms + DevX. This technology is so bad. The designer always crashes. VS rebuild is not working (my workaround: delete bin and obj by hand). And the DevX library has so many bugs and memory leaks. This plattform ist my personally Horror.
I asked collegues how to work effective with the plattform and they showed me their multiple 5000 lines code behind files.
I missing my ViewModels. I do not understand the many commemts here that WinForms is good. I have so many problems with it.
UWP, WPF and Windows Forms will be supported on .Net Core 3
The enterprise development world has about as much interest in UWP as they did in Metro. In other words, between slim and none. Neither is there any interest in the Windows store, corporate or otherwise.
You would be surprised. Now that Windows 10 is taking over the enterprise, the openness to UWP is growing, especially once managers learn they can manage app updates automatically through the corporate windows store. I’ve worked places that already use the corporate windows store to manage software distribution for 3rd party stuff (it does a phenomenal job of managing licensing automatically) and when management is confronted with the nightmare of supporting web, android and ios from a single codebase, the path of least resistance is ditch web and go with Xamarin and publish the apps in their respective store.
Pardon my skepticism but I’ve heard this song and dance before. A few years ago it was “the desktop is dead, Metro is the future so get used to it”. Back then zealots were all over the net preaching the new religion of Metro, how touch was going to take over completely and calling the skeptical Luddites. And with what result? Windows Mobile is dead. Windows tablets never caught on except for Surfaces and they’re used as laptops. Windows Forms, WPF, and Win32 are all still here while the Windows Store is the same old dumpster fire it’s always been. Windows 10 still has a desktop and even virtual desktops while UWP is synonymous with “Candy Crush Soda Saga” and other unwanted garbage Windows 10 downloads without permission.
It’s hardly surprising that there is scant interest in it. UWP is only benefits Microsoft as a way to sell their services. It has little to no benefit for anybody else.
I don’t understand your assertion that UWP only benefits Microsoft. The infrastructure provided by UWP is incredible, and applications are a joy to create and deploy with UWP. The day of the MSI and InstallShield are dying. I’ve gotten very familiar with writing apps in UWP and with Azure services. The ability to leverage the scale and simplicity of dealing with these technologies trumps anything you could do with Win32 stuff. UWP isn’t just about UI, although you can make much better UI with UWP that doesn’t care if you’re using a mouse or a touchscreen. For decades Microsoft has introduced new app paradigms that people have had to be drug into kicking and screaming, but they wind up drinking the Kool-Aid once they get the feet wet. How many new LoB apps start with MFC or ATL C++, VB6, or Delphi today? 15 years ago anybody pushing a WinForms app was a nutjob. As Winforms grew legs, VB6 and Delphi became yesterday’s news. Microsoft WILL break some eggs.
We still write almost all of our in-house tools using WinForms (though mostly with C# now). They’re faster and easier to write than WPF apps, and they don’t need to look “modern.” It gets the job done in the most efficient way, which is all that really matters.
So so true ! Short highlight but truly accurate. Played with all those technical proposals, and i finally, kept WinForms for ROI, and for future, TypeScript and/or Blazor like tech, depending on customer context. Congrat for your pertinent article !
when it comes to WPF vs forms, it’s like comparing a tricycle to an airplane, sure the airplane is much more difficult to operate, the tricycle is easy, but you can only go so fast and so far, I find it funny how all the non-WPF know so much about it, kinda like the 4 year old aviation expert , “I can get anywhere I want or need to go on my three wheels, slow and steady I Say!”
Microsoft is re-writing Windows screens with WPF, they are killing softly Windows Control Panel every new Win10 update. They are smart, they are killing them selfs before some one does. I did program VB 16bits, 32bits until 2010 and migrate to C#, very best then VB by the way, and now I’m migrating my WinForms(C#) to WPF that is best to resize on any screen size. I’m not against any opinion, I just say what I’m doing now. I do program in ASP.NET AJAX using Telerik and I hope some day MS allow us to unify the environment and program to any OS or device, web/desktop/cloud/phone with the same source code, using meta-forms and meta-commands. I’m already implementing .NET Standard to work with WinForms/WPF and ASP.NET, it detect the environment and return the appropriate code with nice success until now. Good luck for all us.
[…] Note: I originally wrote this for SubMain. You can read the original here. […]
1) If you need LOB, WinForms are good enough, even excellent for that matter.
2) If you need some complex graphics (e.g. video game) you are going to use Unity.
For something in between, its still more productive to use WinForms with 3th parties, than WPF and UWP. That is why WinForms are not about to go away in next 10+ years. The only thing could “kill” WinForms may be webassembly frameworks like Blazor or so… But sill, there is too much code in WinForms, it takes millions to rewrite it.
Finally, its not all about technology, its about developers. Experienced, smart devs will always write decoupled, readable code, no matter what tech stack they use
I develop very specialized applications and WinForms paired with DevExpress is very hard to beat. Yes, you need to have Windows but I don’t build products that sell to Mac users in any large amount. If I need web, then I use DevExpress’ ASP components. Any application that that requires heavy UI, you’re much more productive with a Winforms application if mobile and Mac is not a concern. I also employ a lot of web services with remote databases that makes it more of a hybrid application.
Professionally, I manage several development teams and we do everything in a Java backend with an Angular UI and I’m always disappointed by the clunky and limited UI.
DevExpress looks really good. Thanks for introducing me to it. I think I will be going with Winforms + DevExpress for my new LoB desktop application.
I am 17 years VB/C# developer since VB6, I would like to say, if desktop application end of its life , WPF will be dead early then Winform.
Can any one answer when ERP solutions as SAP B1, SAP S4/HANA, Microsoft Dynamic Family and will be died. Although they can run from web browse. And there are many other systems like LS Retail, iVend, Retail Pro… But SAP developers are still coding in windows form. Not be .NET MVC, PHP or Python.
WinForms to me is still useful to me because every 9-12 months when I want to pick up UWP I start a project and am reminded why it’s so limiting. I’m writing a Telnet client, and I want to keep the TCP/IP connection open in the app even when the screen is locked. But for a store app, it’s required to go into this pause state (you can’t opt out of AND be in the store).. this breaks the TCP/IP connection. You ask, users know about this requirement, let them decide. You’re told “RAWRRRR BATTERY LIFE, RAWRRRRR SECURITY!”. These two responses are the two responses you’ll get to every UWP question along with “Why would you want to do that?”. You’re like, hey, the RichEditBox gets -really- slow at about 4000 lines. You get a response like “Why would you EVER want to open a file that big… DON’T DO IT?” to which I think “hey pal, if I want to open a file that’s 4000 lines long I should easily be able to do it… for Pete’s sake I could have done this in Visual Basic 3 on a 386 and have it run faster, if UWP can’t handle a edit box with 4000 lines it’s junk, period”. Then I fall back to WPF or WinForms to accomplish these tasks because they work and they’re not limited. These reasons are EXACTLY why there are hardly any useful apps in the Windows Store. Until Microsoft recognizes this they’ll continue to have sub par apps in the store because every super useful break through app will find the store requirements too limiting.
So mature and still no nullable value support for all controls.
hey guys, windows forms is not dead at all. it is still used for data centric enterprise application. In Europe it is used extensively in the banking, and financial sectors quite a lot. Microsoft also ported it to .NET Core. Is it dead??? Not at all!
Check out Wisej. It?s basically WinForms on HTML5.
For the past 3 years I’ve been working on a project in winforms. Getting to this page is just me researching a small part of it. To me it’s not dead, but I am not by any means a pro programmer. I don’t think it’s dead, but I do think that many many aspects of it could be improved. I hope to release my program in 2020 and am hoping it will help to let us know it can still be used to make some great things that can save a ton of time. Windows is still young and hopefully they will turn things around. I’ve tried wpf and in fact made a whole version of my program in it.. but it couldn’t do what I needed so I switched to something that could. Funny how I’m constantly looking at older/less buggy tech than the newer FAR more buggy tech to make stuff.
Of course WinForms isn’t dead. WinForms is closer to a native windows wrapper. It isn’t going to see new major developments because Win API hasn’t seen any major changes where windows are concerned. Nor should it. WinForms will die when CreateWindow dies. Supporting it and MFC is a no brainer.
The WinForms UI is as old as windows. The controls in use have not change much since the late eighties and applications were written in C code and a the windows message loop. Applications now hide the Windows Message loop but its still there as a integral part of Windows. There are hundreds of thousands of WinForms applications still in existence used in homes and businesses. WinForms applications are very efficient but deployment on a large scale is difficult. Its the battle of Distributed (WinForms) versus the Centralised (Web) application model that has been going on for more than forty years. There will always be a place for WinForms applications.
I have been programming mainframes since 1980 and Windows C applications since about 1989.
At that time Mainframes performed the centralised role that Web applications do today, and Windows API “C” applications performed the decentralised role that WinForms applications do today, but they weren’t called WinForms at that time.
We use Web applications today for the same reasons we used Mainframes then, and we use WinForms applications for the same reasons we used Windows API applications then.
(WinForms is actually just the Dot Net Framework driving the Windows API, just like the VB1 to VB6 runtime system drives the Windows API.)
The main difference is that the Internet has brought computer communication into ours homes and business.
Despite all the hype, I don?t believe that there have been very many productivity improvements in software engineering since the 1980?s. The only exception perhaps being the now widespread use of SQL. (SQL was around in the 1980?s but not widely available.)
The ground shaking improvements have been in Network Bandwidth, Wireless Technology, Processor Speed, Graphics Resolution and Data Storage Capacity.
If you think WinForms applications are dying, then we you will have to explain what will fill the gap.
If WinForms disappears, how will the internet supply the lightning fast performance, high quality interfaces, security, privacy, low cost and the lack of reliance on connectivity. These are the reasons for WinForms applications existence. How will the Windows Operating system even run without WinForms? Mush of the Windows OS is written using WinForms.
Over the years many people have made claims about the productivity of new development concepts and about the demise of some technology. I can think of many that never even nearly came true.
I don’t touch winform since wpf b?ta 2… Winform has a really bad code design, and it’s too directly dependent of win32 by the way wpf depends of direct 3d, but it’s architecture makes port to opengl possible without touching 90% of the code.
[…] question is a reaction to an article I wrote for the SubMain blog on WinForms. It’s geared towards developers, but the core of it is that WinForms can still be a good […]
We had to research this recently for the UI of a new project. Our software is for use within the company, with users split more or less evenly between Windows and Linux. We looked at lots of cross-platform options, but the conclusion was to use WinForms. With a little care the same CIL will run on both platforms with very little platform specific code, using mono on the Linux boxes. Literally halving our dev time was a no-brainer, and while using “mature” technology isn’t so sexy it sure is reliable. Well. so far!
The problem is Microsoft. Their strategy has been a mess since they were so impressed by Apple they try to mimic. Microsoft always tries to force people to move the direction the company wants so they do weird choices but change their mind mid way.
I liked the way winforms was easy to learn but hated the bugs and the diffulties to custromize the UI. WPF on the other hand is a real mess, hard to learn, still not that cool after all and now almost dead.
I wish Microsoft had updated and bettern winforms with new UI functionnalities, …
I plan to continue writing WinForms applications for the next 50 years in contexts where spending shitloads of time on GUI does not make sense. The only thing that can make me abandon WinForms is if something that makes development even faster appears (as measured empirically, hypothetical improvements in new software techs rarely hold water).
Someone said to me a few days ago: “I need a small software to keep records of offers for my business…” My next thoughts: “New WinForms application, new DataGridView, new BindingSource, some SQLite, 1 SSRS, done. Sssss, forget WPF [self]…. ssssss, forget it. dont go that road ever again. Just take the money and let go…”
Winform is still very useful in Industrial transformation, it is sufficient enough to create custom software to communicate between operators & machines!
Apart from that, it is also a beneficial to develop Data Acquisition System in most factories, as we usually use WinsForm to do Logging of data into DB/Cloud
With WinForms you can just code in C# against all desktop (non-UWP) Win32 API without restrictions. For example, we use DirectX 11 interfaces from WinForms to create fluid and modern looking apps with touch support in C#. In the theory, UWP would be more handy in our case. But it doesn’t work on Windows 7, has many restrictions because of sand-boxing, and impose additional complexity brought by XAML-based infrastructure. You can just consider WinForms as a low-level platform which is open up to any design ideas. The future is probably WinUI in Desktop. Classes from Microsoft.UI.Composition namespace look very promising. The only my complain is about XAML.Google’s Jetpack Compose approach looks more handy and sometimes even more powerful in comparison with XAML.
The only thing WinForms is good for is writing applications.