News

Microsoft Says '.NET 5/6 Will Not Be Coming to UWP Project Types,' Developers Sound Off

UWP deprecation angst is back in vogue.

Developers have for years been decrying a perceived neglect on the part of Microsoft toward its Universal Windows Platform, and they're in voice again after the company published new guidance about migrating UWP apps to the new Windows App SDK, which used to be called Project Reunion.

The Windows App SDK is a unified set of of libraries, frameworks, components and tools that developers can use to consistently create any desktop app on OS versions ranging from Windows 11 down to Windows 10 version 1809. The company calls it the evolution of Windows desktop app development, designed to alleviate the complexity of Windows app development that was caused by the emergence of two disparate sets of APIs: for the older Win32 platform and the newer UWP.

The Win32 API was the original C/C++ platform for native Windows apps, providing close-to-the-metal performance with direct access to system hardware. It's still used for what is often called "classic Windows desktop development." UWP, a "modern" take on Windows development, provides a common type system and application model and APIs for all Windows 10 devices. UWP effectively containerizes these apps with lower privilege levels and package identity delivered via an MSIX installer. The Windows App SDK unifies these disparate API sets by basically decoupling them from the OS and providing them to developers via NuGet. It was introduced under the temporary moniker Project Reunion in order to simplify Windows development, of which the company said "we have heard that Windows development is hard. It's harder than it should be. It's harder than it needs to be."

Windows App SDK
[Click on image for larger view.] Windows App SDK (source: Microsoft).

On Oct. 18, Microsoft published "Overall migration strategy" documentation that appeared to walk a fine line between encouraging UWP migrations to the Windows App SDK without claiming outright that UWP is being deprecated.

However, an accompanying GitHub discussion titled "Developing for Windows with the Windows App SDK," which serves as a migration Q&A, provides an indication of the company's thoughts. That the six-item discussion is aimed directly at UWP developers is made clear by the mention of "UWP" 16 times (with many more in the comments section).

The discussion says "For developers using the Universal Windows Platform (UWP) project types, if you are happy with your current functionality in UWP, there is no need to migrate your project type. WinUI 2.x and the Windows SDK will continue to support UWP project types, including bug, reliability, and security fixes." Saying that UWP project types will continue to see "bug, reliability, and security fixes" is the same as saying UWP project types won't be getting much dev love or many new features and functionality.

The discussion also says, "If you need to use .NET 5/6 in your UWP project type, we recommend you migrate your project to a WinUI 3 desktop project, since .NET 5/6 will not be coming to UWP project types."

The discussion generated many comments and replies, with the discourse still going on just an hour or so before this article was written. Here are some of the complaints:

  • Go from Win32 => Windows 8, Windows Phone Runtime => UWP => Win32. Great job MS, you make us waste our time.
  • We've been promised faster compile times for quite a while now, until MS changes its tune and said "UWP is not the way forward".
  • What are you guys even doing? Why are you not improving UWP instead of constantly creating new frameworks? Now we are back to WinForm/WPF and Win32 with fancy incompleted WinUI3? Don't you think it's embarrassing that a massive platform like Windows has 0 competent app development platform for years, almost a decade? Windows is one of the olders platforms ... Meanwhile you keep running around in circles ... truly no words for this.
  • I simply don't understand how you can tell us "if you're happy with your current functionality in UWP" -- we're pretty much 8 years behind any decent advance there has been made.

The developer who wrote that last comment even went on to list some of the bad things about UWP/WinRT:

  • Compile times - I think they are 5-10 times slower than win32. Can't any more compare, I did some comparisons a looong time ago. Right now, my app compiles in about 1:45 min on a very fast computer. Any infinitesimal chance will trigger a 30-45sec or more re-compile. Sometimes it takes longer to compile after a change than to re-compile from scratch -- it's laughable. To make this manageable, I have 15 test projects and I test parts of the app like that.
  • Dealing with the file system: I'm not even gonna go deep on this one, cause just thinking about it makes me go insane. Just the other day, I wanted to improve one of my apps, to open a file with notepad++, and go to a certain line (so basically I would have to call notepad++ from the command line). Yeah guess what - it's impossible. GC: the GC on .net 2.1 sucks big time, and I've spent countless days optimizing so that GC blocking is as little as possible, but to no avail. It still happens. There are advances on GC for .net 5/6 but they will not be ported back (I did ask)
  • Loss of stack trace in async calls: so lets say your app crashes on the client side, and you want to take a look at the stack trace - probably 30% of the time it's lost, because: I have no idea.
  • Access violations: every now and then, you get one of those, which crashes you app, you're basically in the dark - your app is not notified, it's simply a "whatever bro". Sometimes I'm lucky and catch and repro this myself (lol, I'm lucky😁) -- and after a few hours I do get to the bottom of it and fix it. But what about those times when no one bothers to report it?
  • Problems with auto-update (.appinstaller) - you folks created a bug about 1.5 years ago that basically fails to install updates until the user reboots. And you simply don't care about it, and anyone using auto updates would have to tell their users to reboot. Which is insane -- I simply turned off the default auto-update on my app, and implemented my own update mechanism
  • Corruption of intermediary files when moving from one project to another - I have lots of test projects to test parts of my app. When I'd change the active project and hit compile, sometimes I'd run into some weird compile error. The solution? "Clean Solution", or sometimes, reboot.
  • Profiling - sorry to say, but MS Profiling tools are really really bad, compared to Jetbrains. While on win32, I could figure out my bottlenecks in minutes. With Profiling on UWP (Jetbrains's tools don't work on UWP, I wonder why) -- it's horrible. What was minutes turns into hours or maybe days.
  • Upgrading to the latest WinUI2 -- would mean upgrading the Windows target version to 1903 or something. Two months ago or something, tried just that. It made my compile times go 3x (so yeah, >5 minutes!) and startup time increase 8x. So yeah, NO. So yeah, I'm still on WinUI 2.3 because of compile issues -- I can't waste my life waiting for stuff to compile.

For those who do want to migrate, more documentation that went up yesterday, explains "What is supported when migrating from UWP to WinUI 3."

WinUI 3 is a vital component of the Windows App SDK that provides the native UI layer for Windows that embodies Fluent Design and delivers modern, performant and polished user experiences to both Win32 and UWP apps, in Microsoft verbiage. It's one of three primary Windows App SDK components:

  • Windows UI Library (WinUI) 3. This is the premiere native user interface (UI) framework for Windows desktop apps.
  • Visual Studio project templates for developing WinUI 3 apps with full access to the features in the Windows App SDK.
  • Unified APIs for managing app instancing and activation, windowing, resource management, and much more.

"WinUI 3 and the Windows App SDK are new technologies and, when compared to UWP, there are some features that still aren't supported," Microsoft's new documentation says. "This topic provides information to ensure that you know whether all the features you need for your are supported before you attempt migration."

What is supported when migrating from UWP to WinUI 3
[Click on image for larger view.] What Is Supported when Migrating from UWP to WinUI 3 (source: Microsoft).

The above graphic from that documentation illustrates that some UWP features aren't yet supported in WinUI 3.

Packaged App Support
[Click on image for larger view.] Packaged App Support (source: Microsoft).
Unpackaged App Support
[Click on image for larger view.] Unpackaged App Support (source: Microsoft).

As far as the progress of the Windows App SDK itself, the above graphics (for packaged and unpackaged apps) from the project's roadmap show the features supported in the latest version, v0.8, what's coming in the GA release before year's end and what's planned for future releases after that.

Ironically, the revived uproar about the demise of UWP comes just a little over a month after the UWP community announced the winners of its Launch 2021 event that celebrates UWP apps and their development.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube