UWP vs Desktop

[adderthorn]

I read through some of the documentation and FAQs on reunion as well as a few Channel 9 videos on WinUI 3 and project reunion. My question is on greenfield development. If I am starting to write a new app, in C#, and targeting a desktop audience, what is the recommended approach between desktop and UWP? I understand UWP's packaged and container model, but assuming those things are unimportant, does UWP continue to be the recommended approach unless my needs cannot be met with its limitations?

[wjk]

I would recommend that you don’t create a UWP app — yet. The UWP app development experience is currently very crappy and prevents you from using about eight years’ worth of toolchain and library improvements. If you create a WinUI 3 desktop app, you can easily port it into UWP-land (really the CoreWindow lifecycle) once it is compatible (WinUI is currently supported in desktop apps only). You would create a WinUI 3 desktop app (using the desktop app template), put it in an MSIX package, and mark it as being a CoreWindow/AppContainer app by using code in the MSIX package manifest. This makes it run as a ”UWP app” without needing to deal with the horrible outdated UWP toolchain that Visual Studio still requires us to use. Unfortunately, there is currently a bug in VS that prevents you from easily doing this.

However, that being said, if you are planning on using MSIX to distribute your program, you can instruct Windows to keep your desktop app in an AppContainer sandbox despite it being written using Win32, WPF, or other non-UWP UI stacks. (I don’t know how well you would be able to request access outside of that sandbox if you’re using this technique; I have never tried it myself.) Hope this helps!

[maxkatz6]

I don’t know how well you would be able to request access outside of that sandbox if you’re using this technique;

If you use MSIX with Win32 app, your app isn't restricted in the way as UWP was (comparing with non-MSIX installation). Only one difference AFAIK it that app doesn't have write access to the installation folder. It's important moment, but makes sense and it's possible to adapt the app.

[DrusTheAxe]

Only one difference AFAIK it that app doesn't have write access to the installation folder. It's important moment, but makes sense and it's possible to adapt the app.

And even that's not absolute. For instance, your package can manifest <Extension Category="windows.mutablePackageDirectories> to provide writable access to the package content.

There's also ExternalLocation for a Sparse Package. If you have your own installer then your files are...wherever you put them. Your installer 'owns' them so you're free to write to them as you choose.

[maxkatz6]

@DrusTheAxe oh, didn't know about that. Thanks!

[DrusTheAxe]

P.S. The windows.mutablePackageDirectories extension is a machine-wide operation (not per-user) so installing a package containing one requires the modifiableApp restricted capability (rescap) as well as admin privilege (aka elevation). That may or may not fit your needs.

P.P.S. ExternalLocation supports per-user as well as per-machine behavior. You get a per-machine ExternalLocation if your stage the package (e.g. packageManager.StagePackageAsync()), and being a machine operation will require admin privilege. If you install a package with an ExternalLocation without staging it (AddPackageAsync, RegisterPackageAsync, etc) then you get a per-user ExternalLocation, and of course no admin privilege required.

[riverar]

@DrusTheAxe Actually, the user is not required to elevate during install or use. That operation is handled by Windows (and was recently subject to exploitation via CVE-2020-16877).

[riverar]

"UWP" is ill-defined, so it's hard to have a conversation without defining up front what you're referring to. But I suspect you're referring to the classic mix of appcontainer/corewindow/WinRT XAML. Microsoft no longer recommends this path, although getting this message to all its employees is... a work-in-progress. Microsoft is working on migrating folks from "UWP" + WinRT XAML to "Project Reunion" + WinUI XAML. We're still in the middle of this Great Windows Developer Migration so things are rough right now and everyone is a bit grumpy.

Your options are:

• Minimally package your application with MSIX, get access to WinUI 3 for UI framework (or keep using WPF/WinForms), and you can use Win32/WinRT/COM/etc. API as you wish, get mostly unrestricted system access with use of runFullTrust, and access to the Microsoft Store.
• Do not package your application, you're pretty much stuck with raw WPF/WinForms for now. Might be able to use XAML Islands depending on your scenario.
• Wait for Q4 2021 and see if Project Reunion + WinUI 3 support for unpackaged apps materializes

There's a lot of room for nuance here, so do clarify your needs where possible and someone will point you in the right direction.

[riverar]

@adderthorn: @maxkatz6 and @Pinox definitely touch on a reason you'd stick with UWP today. It's your only option for targeting Windows 10 IoT, Xbox, HoloLens, or Surface Hub for now. I suspect we'll see some of those walls come down eventually but it's going to be a slow process. They aren't popular targets for windows developers so I suspect it's not a high priority at Microsoft.

[jtorjo]

Today with phone out of the picture, store available for other app types, and Win UI 3 available for desktop, why should someone choose UWP today?

I was forced to use UWP because of win2d. I still have nightmares about it. I've been asking for close to 2 years about whether win2d will come to WinUI Desktop, and while it appears it will be so, I've never been given a clear date.

Long story short, if you need win2d, you will probably be stuck with UWP.

[Symbai]

UWP obviously compile to native code , that's a big plus for performance and also security of source code

So using WinUI3 and choosing this MSIX (and later the unpackaged version) is not native code? (Serious question, I'm looking forward for WinUI3, got the same question than the thread operator but never used UWP/WinUI3 before).

[contextfree]

@Symbai WinUI3 is native code (C++), whether used with MSIX or not.

I think @Pinox was assuming a C# app and thinking of the different versions of .NET available currently for UWP vs. Win32 apps (.NET Native vs. .NET 5/6). With .NET Native on UWP, C# code is compiled to native ahead of time (AOT); .NET 5/6 are more modern, allowing the use of the latest C# language features and APIs, but they're compiled just-in-time (JIT), like .NET Framework, which means faster compile times but can mean slower startup and runtime performance.

Neither UWP nor WinUI3 require using C# or .NET at all though.

[Symbai]

I meant WinUI3 with C# targeting desktop. WIth all the "uwp-like" behaviors (package project, publishing only to msix, enabling debug mode in Windows settings just to be able to run it in VS debug etc) I expected it to be an UWP app with native code. But you are right, I published it and opened it with dnSpy, its still JIT code. In this case I have no understanding for the msix restriction. But once its lifted it seems to be a good choice when you only target Windows and you cannot choose UWP because of its sandbox.

[ccarlo88]

[ghost]

current CEO wants your soul to run on Azure (provided that you are not a naturalist); what more do you want huh?! unlike steve ballmer, current CEO is visionary but that vision only operates for cloud and only cloud.

[shelllet]

It is because I saw that winui 3 can develop Desktop app using win32, and can be released as none-msix package, my project is slowly converted to here, and include other projects in the future, I believe there will be more developers like me .