Windows Presentation Foundation (WPF) has been released as part of the .NET framework 3.0 in 2006. It was one year before Apple released its iPhone. Many .NET Framework versions later, it got improved, and it’s still there. In 2019, WPF is in its 13th year which raises the question if WPF is still a good choice?
What is WPF?
Windows Presentation Foundation (WPF) is a UI framework for building Windows desktop applications. It uses the Extensible Application Markup Language (XAML) to define views in a declarative way. It has built-in support for resources, graphics, data binding and much more. It’s a very feature rich UI framework.
WPF is open source
On December 4th, 2018 Scott Hanselman announced on his blog that WPF, WinForms, and WinUI are being open-sourced by Microsoft on the same day as .NET Core 3.0 Preview 1 was announced.
Open sourcing means that the community has the option to contribute features and bugfixes to the technology. Microsoft has proved that they care about open source and open sourcing WPF is a strong sign that Microsoft also cares about the future for WPF.
It is worth mentioning that Microsoft did not publish the sources of the existing WPF implementation to GitHub, but they reacted a repository called WPF for .NET Core, which indicates that it’s a specific code base targeting the .NET Core platform.
Microsoft Roadmap 2019
Microsoft’s official 2019 WPF roadmap states that functional and performance parity compared to the .NET Framework are set goals in regards to the release of .NET Core 3.0.
The roadmap also states that there needs work to be done in order to have all components available and that they are working on the process of how to validate and merge community pull requests.
The impact of .NET core
With the upcoming release of .NET Core 3.0 Microsoft adds WPF support to the new generation of .NET. That also gives you the opportunity to ship a specific version of the .NET (Core) framework with your application instead of relying on a specific version installed on your customer’s machines.
It is a big statement from Microsoft to move WPF to .NET core. In my opinion, this move shows that Microsoft continues to believe in the future of WPF as a UI framework for the .NET platform. They invest a lot of money into open-sourcing it and making it run on .NET core.
One of the biggest benefits of this move is that you are no longer boxed into the (full) .NET framework if you want to build a WPF application. You now have the same choice for front-end products that backend developers already had since .NET core 1.0. You can now choose if you want to write your application for the new or the established platform. Having a choice is great.
Because WPF (and WinForms) use a lot of Windows-specific features, WPF applications will only run on Windows. It’s also true for WPF applications targeting the .NET core platform. That is somewhat unintuitive because .NET core is best known as a cross-platform framework, but makes sense if you think about the history of WPF.
What about existing applications?
Do we have to migrate existing applications to .NET Core? No, we don’t, but we can. Microsoft suggests that new projects should be considered building on the new .NET Core platform where existing legacy apps which are in maintenance mode and are not business critical can remain on .NET Framework. The (full) .NET framework will still be available for a long time.
Advantages of .NET Core for Desktop
1. Your application runs on the newest .NET technology which was written from scratch resulting in a much better performance. Some of the legacy stuff from the early days that could not be removed from the (full) .NET Framework were not transferred to the .NET Core platform. All of this makes it much more efficient.
2. You can run your applications side-by-side using different .NET Core versions. That allows your application to be independent of the .NET frameworks installed on your computer or your customer’s computer.
3. You gain access to the newest features in Visual Studio around the new project file format, tools and SDKs which were created for applications using the .NET Core platform.
4. Building your application becomes faster which results in less effort (time & money spent). That is especially helpful in regards to continuous integration and continuous delivery.
From the .NET blog:
“Know that if you have existing .NET Framework apps that there is no pressure to port them to .NET Core. We will be adding features to .NET Framework 4.8 to support new desktop scenarios. While we do recommend that new desktop apps should consider targeting .NET Core, the .NET Framework will keep the high compatibility bar and will provide support for your apps for a very long time to come.”
Alternatives
Not in the scope of this article, but also worth mentioning is that there are community created alternatives for the .NET Core platform:
- Platform Uno allows you to write C# and XAML code to build web and mobile applications targeting Android and iOS. It also provides a Universal Windows Platform (UWP) bridge.
- Avalonia is a cross-platform XAML framework for .NET Framework, .NET Core and Mono. As it supports .NET Core and Mono it runs not only on Windows but also on Linux. It also features experimental mobile support for Android and iOS.
Of course, there are other projects including Blazor and Ooui which leverage your C# and .NET skills to build applications for the web.
Conclusion
In my opinion, WPF is still a valuable and relevant framework for building .NET applications in 2019 for both the .NET Framework and for .NET Core. If you have a team or company familiar with the tools why shouldn’t you use this advantage? Use something new, just because it’s shiny? Does not make any sense for me.
If I was in the situation where I have existing applications I would carefully evaluate for each application if migrating to .NET Core makes sense and how much effort it would take to do so. As explained in this article, there are many benefits of running on the .NET Core platform which you could leverage for your application.
One important aspect is that there is a big eco-system around WPF. There are UI frameworks like Telerik or DevExpress which enhance the functionality even further. There are also MVVM frameworks which help you decouple view logic and business logic.
And because WPF is around for a long time, it can be considered stable. There won’t be breaking changes in every further release, and there won’t be silly bugs in commonly used components.
It depends on the requirements of a new project if WPF is an option. When it comes to a Windows (only) Desktop client, WPF can still be a viable option.
The alternatives mentioned above give us many different options to choose from. There is still a very healthy eco-system around Windows Desktop application development, although web and mobile are going through the roof.
Further Resources
2019 : The entire business world is moving it’s applications from WPF to Angular or similar. Sorry. It’s dead. MVC is about to die soon. SPAs eventually won.
Maybe MVC will be replaced by ASP. NET Core, but I think WPF will be a valid solution for desktop high performance enterprise applications for a long time.
@Panos.R I don’t think that’s true, or at least not as widespread as you make it out to be. If they are converting/rebuilding existing apps as an SPA , what exactly is the rationale? What would the advantage be , especially now that WPF has guaranteed future support (due to Netcore3) ?
Businesses generally convert only when:
1) There is some big improvement in performance that will help productivity
2) There will be more useful features that will help productivity,
3) There are worries about whether they’ll be able to continue to deploy and maintain an app.
4) Other apps that use the existing one as a template continue to be built and that would go much faster inside another platform.
5) There are complex controls they can easily find examples for in other environments that aren’t difficult to customize.
On none of the first three fronts does it make the least bit of sense to migrate existing WPF apps to some other platform.
1)If there are performance issues in LOB app– enough to matter–it is the architect’s fault, not WPF. Yes, there is a learning curve but there are also a LOT of ways to tune performance.
2) If one is malcontent about WPF’s features, one doesn’t understand WPF very thoroughly: it is designed to be a self-contained system for creating complex controls (that are usually combinations of more primitive controls), and every single aspect of each of the component’s behaviors can be tuned. This makes it a good deal more powerful than Winforms, and gives architects the same level of fine-tuned control just using XAML and the stock Framework components, without a million little dependencies on JavaScript frameworks, which tend to have a short shelf-life.
3) Netcore3’s support for WPF should dispel any concerns about deployment.
Only the last two items should even be a consideration–and they are only relevant to the building of NEW apps, not migrating existing ones.
Regarding #4, WPF has never been a RAD environment. The tooling is not as good or numerous as with HTML, and the binding approaches are a lot harder than with Winforms. Still, if a team learns to reuse their existing work, all this difference can be minimized, negated really. Actually, despite way XAML at times , one can add child controls to any panel object very easily just using C#. Why more don’t do that is quite beyond me. Perhaps it is because the MVVM principle is often stressed, and that allows keeping all the View-specific code entirely in XAML, which seems to be important to many from a S.O.C. standpoint.
Regarding #5, I’ll admit that here that WPF falls far behind behind in terms of usable examples, and in the sheer number of controls available in web platforms, but there are still plenty of third party controls–enough to get the job done at any rate. Also,I question how easy it is to customize the more complex controls in other platforms by comparison. If it’s easier, it’s usually just because more people are using it, so there are more code examples to draw one. More to the point though: there really isn’t much of need for 3rd party controls in WPF in the first place–it is designed to be self-contained and allow one to create any kind of control one desires. In a worst case scenario, developers have to resort to a third-party control for something more complex like a hierarchical-view datagrid just because it would take them to much time and energy to build one their self.
It bears mentioning that the alternatives worth considering are almost all server-side technologies, not client. We’re just now starting to see an option for building SPA’s using client-side C# instead of JavaScript really take root. Only recently has Blazor (which gives a client-side option for C# development) become a fully-supported Microsoft platform. And as far as I can tell, the client-side option in Blazor still requires a web server to deploy the clients. I don’t think it’s a true fat-client technology, in other words. More fundamentally: to do what WPF does natively would require a bunch of JavaScript frameworks likely to go obsolete soon and need updating. Plus, and I’m not sure how simple it would be when it comes to all of the in-memory and asynchronous stuff. If there IS going to be a replacement for WPF, my money is on Blazor client-side, but unless there is an easy way to do everything WPF can and deploy it to a client without a web server, I think it’s moot.
Finally, if the goal is to move to an HTML-based alternative, we have to take it on good faith that somehow this will result in LESS rework of existing apps going forward, not more. Frankly, I believe it’s absurd to think hat a move to any HTML5-based platform is going to require less rework . We’ve heard for years the desktop was dead and yet we’ve seen several versions of ASP come and go, and many more little JavaScript frameworks do the same. Meanwhile, WPF has been able to do all of the same kinds of things natively, without all of the external dependencies, in a highly object-oriented language, with full aforethought given to design patterns.
The irony is that when you read about Blazor, the press statements say things like “wouldn’t it be great to have C# client-side scripting inside a web app?” LOL. Well, yes, it certainly would be….almost like we had 15 years ago with Silverlight!
The real reasons you see a shift towards HTML platforms nowadays is because a) Google decided to stop supporting most RIA plugins to make their browser a bit faster b) HTML/JavaScript started being able to do some of the client-side stuff WPF could (although how adequately and relatively easily/cleanly is debatable) and c) there is a moronic obsession over everything being cross-platform compatible. I say it’s moronic because if deploying a Windows-based LOB app internally in your company were such an obstacle , you would probably never have been able to in the first place. For Christ’s , Citrix Xenapp, folks! Problem solved. This one area where there is a huge chasm between the needs of free-lancers and internal development shops in big corporations. For the former, there is a legitimate need for everything to work in every browser, on every OS. For the latter, there never was a need in the first place, and having to deal with all the numerous the DOM -related annoyances of the web stack. But for years and years–actually before WPF even came around–herd-thinking IT managers would insist the desktop was done for and insist on near everything being built as a web-app. That has never been the case , nor could it ever be the case, although clearly most apps can be deployed to the web, and the line between web app and thick client has once again gotten a bit blurry.
Finally, the most obvious reason why people keep spreading the idea that WPF is “dead” is because there simply isn’t much left to add to it at this point. It is fast, flexible and entirely self-contained in a way that other platforms simply aren’t. Age-wise, is “mature” in the same sense that Winforms is. So why would we expect more and more to keep getting added? Not that I wouldn’t like to see SOME more features and better tooling, but at the end of the day, I and others can get the job done just fine using Visual Studio. If ones wants more and more new features (as opposed to less rework and more shelf-life), then one should be looking at the latest HTML flavor-of-the-month. Frankly, talking about lack of features with WPF is just silly. All the gripes I hear about features come from people who are misinformed about its current capabilities, or else are focused on nitpicky things that wouldn’t be impediments to anyone building an internal LOB business app (which is most developers). What are really worried about is that someday, if WPF popularity declines enough, Microsoft will one day just yank the plug like they did with VB6.
There is simply no reason to suppose that will happen. As the author points out, WPF support isn’t going any where. WPF itself isn’t going to evolve much going forward though. There’s not sufficient demand nor much of a reason for it to. If you want to play with new toys and feel part of the in-crowd , go grab the Blazor, Spark, or some other SPA platform. In a few years, one of those might be able to do what we’ve been able to do in WPF all along.
very good. i use WPF with roslyn and compiler in runtime and store code xaml and c# Into sql server
It’s going to be ending of mine day, however before end I am reading this fantastic post to improve my know-how.