19

We're starting a new project and are trying to decide to use either Windows Forms or WPF.

I've read some of the other Stack Overflow posts, and realize that WPF has some advantages in the data-binding and appearance areas, but also has a steep learning curve and fairly immature tools and controls.

We would like to better understand if Microsoft is planning on stopping new development of the Windows Forms technology and forcing all new development to eventually go to WPF, or if both technologies will be maintained and improved. (Or are they just going to wait and see how it goes before making up their mind?)

Currently, it seems like WPF is not necessarily the best way to go for line of business applications that don't need extra bells and whistles in the UI. However, it would be good to know if WPF is something we'll need to embrace sooner or later.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
alchemical
  • 13,559
  • 23
  • 83
  • 110
  • Possible duplicate: *[WPF versus Windows Forms](http://stackoverflow.com/questions/202079)* – Peter Mortensen Oct 01 '11 at 14:40
  • Five other possible duplicates: 1. [Is it better to use WPF over Windows Forms?](http://stackoverflow.com/questions/640633), 2. [Migrating from Windows Forms to WPF... was it worth it?](http://stackoverflow.com/questions/534205), 3. [When is Windows Forms the correct choice vs WPF?](http://stackoverflow.com/questions/388711), 4. [WPF, Windows Forms, or something else?](http://stackoverflow.com/questions/504014) and 5. [What are the benefits of using WPF over Windows Forms?](http://stackoverflow.com/questions/897945). – Peter Mortensen Oct 01 '11 at 15:02

7 Answers7

53

This is partially a reasoned argument, and partially a heart-felt rant....

WinForms is based on the user32/GDI technology that has existed since the dawn of modern Windows. It is not going to go anywhere, in all senses of the phrase: it won't get new features; it won't get support dropped.

Or maybe it yet will. The charting API in .NET 4.0 is new and written for GDI, not WPF.

In general, Microsoft has a history with new technologies that looks like the following:

  1. Invent new API.
  2. Innovate with that API for 2 or 3 product cycles.
  3. Realize that continuing to innovate means making unreasonable concessions to backwards compatibility or having realizations that the technology didn't originally address.
  4. Invent new API by wrapping or leaving the existing API around. The existing API doesn't disappear, but new stuff doesn't use it, either.

RDO -> DAO -> ADO -> ADO.NET -> LINQ to SQL -> Entity Framework, toss in some ODBC ... there is a treasure trove of "dead" and wrapped technologies that are still usable and still exist today. These are data access technologies, but the same idea applies; UI frameworks last a little longer because they are the most visible areas of applications.

If I put my Nostradomus hat on, I can safely say that when .NET, oh, 6.0 is out in 2015--which sounds far away but is as close as we are to 2003--WPF will be as "dead" as Windows Forms because some other nifty managed interface will have been created that smoothes over all of the as-yet-undiscovered mistakes and inconveniences of WPF. Who cares? Everything we are yabbering about today will be deprecated by then. (Something is going to have to give in .NET 5.0 anyway because the framework is getting comically large.)

If anything, the thing that Windows Forms has going for it is that it's based on the technology that has existed for well over a decade, and that inertia is not dying anytime soon: the browser you are typing in is using GDI, the taskbar is using GDI, your instant messaging application is using GDI, the new Ribbon control in Windows 7 is using GDI, the $60 printer sitting your desk is using a GDI printer driver, the Windows CE applications running on your phone run a port of Windows Forms and GDI, the new Event Viewer in Windows Vista is using Windows Forms, and there is a large third-party component community behind the Windows Forms platform--WPF is a very small, niche product that only exists in the managed world, which is itself smaller than its unmanaged counterpart.

To this end, I feel that all of these "WinForms vs. WPF" discussions are blowing things out of proportion; the technologies are not mutually exclusive or inferior/superior, as much as Microsoft marketing might have us believe, and Microsoft's developers are smart enough to realize this. They are simply different and one of them happens to be older. If we didn't consider this periodically, we would have all listened to Gartner in 2005 and stopped building Windows applications entirely and moved everything to AJAX on the Web ... with our SOA interfaces ... that expose an alternative REST interface ... that use a TDD DDD model on that backend ... abstracted from the database by an ORM.

Being so eager to abandon a technology for fear of its deprecation only assures our clients that we will maintain a constant level of inexperience and incompetence at programming software solutions.

WPF is part of the future, to be sure, but it's not THE future. Personally, I'm on the fence to see if WPF "makes it" in the UI technology sense that previous data access technologies haven't, although Visual Studio adopting it in 2010 is a pretty comforting sign that Microsoft is actually serious about it by dogfooding it in a flagship product.

To sum up: if you are building a LOB application, I wouldn't feel guilty about using WinForms. If you need an advanced layout scenario, WPF interop is always available to you, just as one enhances a regular Web site occasionally with a Flash object. But for anything else, you owe it to your client to come up with a Good Reason for transitioning the whole team and shell to WPF; Windows Forms has its problems, but half the battle with any platform is knowing what the problems and limitations are, and most of the world (including Microsoft) is still learning WPF.

Nicholas Piasecki
  • 25,203
  • 5
  • 80
  • 91
  • Great answer! In any case, I think I need to ease into WPF and I don't want to "bet" a project schedule on learning it all at once. My feeling is to just have a few WPF controls in a Winform, unless the client understands the risks and still wants to move ahead with the new technology in order to get its potential benefits. – alchemical Jun 07 '09 at 18:40
  • Great post. WPF has a pretty steep learning curve since it does things significantly different from WinForms (data binding is different, layout is different, etc...). But it has powerful functionality once you get the hang of it. – Jon Onstott Jul 15 '09 at 22:55
  • Also, because of the interop between the two, if you have a specific situation in an app that lends itself to WPF, you can host it and use it in just that spot while sticking with WinForms through the rest. I never understood either-or arguments in this context. Use what works best in each case, and MS has been kind enough to really enable powerful mix-&-match scenarios with WinForms and WPF. :) – Greg D Aug 12 '09 at 14:01
  • I would not agree that the charting API is indicitive of anything, esp. since it was a purchase from Dundas who released their product prior to the innovation of WPF. – Jerry Nixon Jan 21 '11 at 17:00
  • You mention dogfooding in Visual Studio. Well, if VS 2010 is any indication, I'm unimpressed. This thing is really slooooooowwwwww. – DOK Sep 26 '11 at 13:32
5

WinForms won't be deprecated until Win32 is ... which could be quite sometime!

(Remembering that WinForms is basically an abstraction over Win32)

WPF on the other hand has few direct dependencies on Win32 so could potentially form the basis of a "fresh start" UI layer on a future version of windows. At which point I would imagine Win32 (and thus WinForms) will be completely ditched and only available through virtualization. As I said this could be along way off :)

Jack Ukleja
  • 13,061
  • 11
  • 72
  • 113
4

Microsoft's support policy for the .NET Framework and all classes within it is 5+5: 5 years of mainstream support after a release, and then 5 years of extended support is available, or a fee.

With the .NET 4.0 update, including all the WinForms stuff, being released in 2009, you will get 5 years of mainstream support, to 2014 for any WinForms app built on .NET 4.0.

It's likely whatever comes after .NET 4.0 will include WinForms, too, in which case the clock resets.

This 5+5 policy applies to all business-related infrastructure software: Windows, Windows Server, SQL Server, Visual Studio, .NET, and so on.

The point is, you won't have to worry about lack of support for WinForms.

But, the prior posters are correct - the advancements are going into WPF.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
2

I wouldn't worry too much about long term support. WPF may be getting all the love lately, but there's too much WinForms code out there to abandon support. After all, even MFC is still getting updates with each Visual Studio release.

Peter Tate
  • 2,178
  • 1
  • 21
  • 32
1

I think Windows Forms will continue to be maintained by Microsoft, but improved upon only in small ways. All of the hot new innovations will go to WPF. Windows Forms is in a similar position as LINQ to SQL. LINQ to SQL is a tight, compact, fast ORM that is awesome, but Microsoft is throwing its weight behind the Entity Framework.

Windows Forms is great for what it is, and what it is used for, which is small, tightly-wrapped applications. It still has many years of life left in it.

If you want an application that will (more) easily port between a web interface, a WPF interface, or a Silverlight (or even a Flex) interface, Windows Forms is probably not for you. These other interfaces use standards-based markup, and an architecture that lends itself better to enterprise development.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
  • 2
    WinForms is perfectly capable of utilizing WCF, web services, and enterprise databases. That's a pretty bold statement. It's been used to power some pretty huge apps for a lot of years, and I'm sure it will continue to be used. I agree (mostly) with your first paragraph, but I honestly think the second paragraph is pretty inaccurate. – Scott Arrington May 27 '09 at 00:56
  • 2
    Thanks for the vote of no confidence Scott. Of course Winforms is capable of enterprise development. The real question is, would you want to, given that Microsoft is putting its weight behind WPF? – Robert Harvey May 27 '09 at 01:12
  • 1
    If you don't need the additional functionality, there's no reason not to. WinForms still has a much more shallow learning curve imo, and not everyone has a designer working for them. – Scott Arrington May 27 '09 at 01:29
  • I'd also agree WCF has no advantages when it comes to WCF, web services, etc. It appears to have a steep learning curve, not just for people transitioning, but for someone who was new to both Winforms and WCF as well... – alchemical May 27 '09 at 16:38
  • you can also minimize the pain of porting your app to a new UI framework/platform by using MCV/MVP patterns – Matt Crouch May 28 '09 at 14:13
0

I went to a WPF preview camp in Redmond a couple of years ago, and I asked this same question to one of the folks working on Crossbow (WPF/Windows Forms interop). His response was that Windows Forms will be supported for the foreseeable future, but could make no guarantees.

Given that, I think you'll be OK basing your application on Windows Forms knowing that you'll have some level of support for the next version or two of .NET (for example, 3-5 years).

I would personally bet closer to 10 years considering Microsoft's continued support for Win32. You may not get boatloads of new features with each release, but you won't be dropped, either.

In any case, I would actually be more concerned with Microsoft's shift from rich-client technologies to web-based technologies, but not enough to ignore opportunities to create compelling applications in either case.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
micahtan
  • 18,530
  • 1
  • 38
  • 33
0

I certainly wouldn't call WinForms dead... but I also wouldn't write a new project in it. I would write all new projects using WPF for a myriad of reasons. The biggest is that if you use WPF/XAML, your porting efforts to Silverlight will be much easier.

Brian Genisio
  • 47,787
  • 16
  • 124
  • 167
  • Porting to Silverlight sounds nice, bu the truth is that most internal Windows Apps we create are windows rather than web for a reason, and we don't anticipate needing to port them. As the say, IAGH. – alchemical May 27 '09 at 16:35
  • It just gives you more flexibility... thats all. – Brian Genisio May 27 '09 at 17:06
  • So, two years later, that ability to port to Silverlight doesn't look so enticing now that Microsoft is basically abandoning it for HTML5 and in Windows 8. It's hard to plan for the future. – DOK Sep 26 '11 at 13:30
  • @DOK M$ is hardly abandoning Silverlight. That is certainly FUD. It is still a strong platform. WinForms, however, has been long forgotten. I stand by what I said over 2 years ago: I wouldn't write a new project in WinForms. – Brian Genisio Sep 26 '11 at 20:23
  • You could just Google "Silverlight is dead" to find dozens of articles about this. [This one](http://www.neowin.net/news/former-microsoft-pm-silverlight-is-dead) says "there's one guy right now whos metrics are to shut Silverlight down as a brand down, most of the team have been split apart and others have left the company altogether." Or there's [Microsoft has Abandoned Silverlight and All Other Plugins in Metro IE](http://www.infoq.com/news/2011/09/Metro-Plug-ins) – DOK Sep 27 '11 at 14:46
  • @DOK: Abandoning Silverlight in Metro is very different from abandoning Silverlight all together. This is still just speculation and doesn't reflect reality. I am well aware of the FUD that is out there... but it really is just that. – Brian Genisio Sep 27 '11 at 16:16