Building LOB Applications with UWP: How Microsoft ROCKED IT at Build
My daily work is building LOB applications for enterprises and creating Azure-based backends. Since 2006 I’ve used mostly WPF for building powerful and data-rich desktop applications. Last year I’ve published a 9 hours course at Pluralsight that is called Building an enterprise application with WPF, MVVM and Entity Framework Code First. It starts from File->New Project in Visual Studio and ends with a full-blown application.
Reasons why customers today use WPF instead of UWP for new projects
As you might know, the Universal Windows Platform (UWP) is the newer beast. It’s an evolution of the Windows Store Apps that were introduced with Windows 8. UWP has some really great features like x:Bind and more. But in the past customers and I have chosen WPF over UWP for enterprise apps, mainly because of these reasons:
- WPF supports input validation with
INotifyDataErrorInfoand Data Annotations - WPF comes with built-in Controls like
DataGridandMenuthat are/were missing in UWP - WPF’s UI density is made for desktop. UWP elements are huge by default. I noticed that when I built the Visual Studio Shell with UWP
- Deployment with WPF and ClickOnce is so simple.
- Customers are using Windows 7, UWP runs only on Windows 10
But this week things changed a bit, because
Microsoft really ROCKED UWP! at BUILD
While the last point with Windows 7 mentioned in the list above will always be an argument for WPF – UWP won’t come to Windows 7 – Microsoft works on the others. And this week at Microsoft’s Build conference, Daniel Jacobson and Ryan Demopoulos really rocked it.
From my 10+ years WPF Line-of-Business (LOB) application building experience, I can tell you that Daniel and Ryan address every – really EVERY!!! important point in their session for building a LOB app with UWP
Watch their session above, it’s a must if you want to build enterprise desktop applications for Windows. It starts from Windows Template Studio – a fantastic Visual Studio Extension for UWP by Clint Rutkas and the community – and goes across UI Density, Input Validation, DataGrid, Menu to Deployment and more. That means this session addresses all the WPF reasons from my list above – except Windows 7 of course.
You find the sample app used in the video here on GitHub.
Beside all these great news, check also out the blog post on .NET Core 3.0. Another great news about WPF, WinForms and UWP, which will all run on .NET Core 3.0, which is amazing!
Let me just quote the end of that .NET Core 3.0 blog post:
“It is an exciting time to be a .NET developer”
Thanks,
Thomas
Comments (5)
Hi,
Any chance to see in near future re-written/re-recorded WPF for Enterprise with UWP for Enterprise?
Cheers
Hi Leszek,
you’re talking about this course? -> https://www.pluralsight.com/courses/wpf-mvvm-entity-framework-app
Yes, in the future I plan to re-record it for UWP/WinUI and Entity Framework Core. But maybe I’ll create a few smaller courses instead of such a big one. But as WinUI will be released 2020, it won’t happen before 2020. :-)
Cheers,
Thomas
Hi Thomas
I have been building industrial engineering software using WPF, it is a great and powerful framework.
I addition to your points, I can add the following
1. WPF and .Net framework is being used by many manufacturers to build their Dlls. and UWP does not support those kind of libraries.
2. Generating PDF reports in WPF is much easier and practical than UWP.
3. WPF is backed with many third party frameworks that does not support UWP.
So the momentum of shifting from WPF will take much longer by the industry, especially such as the one I am living in.
Hi Jawad,
thank you for the input. I agree to all your points. And yes, WPF is typically used for enterprise applications. There WPF is still a great and valid choice, even Windows Forms is. I think with Microsoft decoupling UWP from Windows and providing it as WinUI that runs like WPF on Win32, but also supports the UWP-hosting model if needed, it’s the framework of the future. And it gives you all the modern Windows 10 stuff.
But I agree, the momentum for shifting will take a while.
Thank you,
Thomas
Lack of adoption was a factor in the early days of UWP. It lowered the visibility for Microsoft to get it right. So customers had a role here. I suppose the other problem, if you could call it that, was the fact that WPF was to capable to start with. In the end the biggest failure came from Microsoft. The company refused to listen to the needs of its customers. Under the hood I suspect folks were hiding from the long shadow cast by WPF and Silverlight and the folks that built those frameworks.
The biggest problem for UWP in the beginning was the fact that it was broken in so many ways. It has literally taken years to get to the current level of stability in tooling and APIs, and still some rough edges persist. I blame that on the WinRT redo of the Win32 API. It was a noble idea, universal language projections, a .Net Native compiler, a Store app distribution system, etc., etc., and it appears UWP was overwhelmed by the scope of the task.
WinUI will likely only be good for existing UWP devs. I very much doubt WPF devs will switch over on mass simply because WPF still does the job better and will continue to do so for years to come unless Microsoft plugs all the gaps in UWP/Winui when 3.x finally reaches our shores which is extremely unlikely.
The WPF old timers will know what I mean when I say “Shine on you crazy diamond.”