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:

  1. WPF supports input validation with INotifyDataErrorInfo and Data Annotations
  2. WPF comes with built-in Controls like DataGrid and Menu that are/were missing in UWP
  3. 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
  4. Deployment with WPF and ClickOnce is so simple.
  5. 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”


Share this post

Comments (5)

  • Leszek Reply


    Any chance to see in near future re-written/re-recorded WPF for Enterprise with UWP for Enterprise?

    September 12, 2019 at 10:00 am
  • Jawad S. Jaber Reply

    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.

    April 20, 2020 at 7:29 am
    • Thomas Claudius Huber Reply

      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,

      April 26, 2020 at 10:59 am
  • Noemata Reply

    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.”

    December 29, 2020 at 2:35 am

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.