Updating Maui templates to build unpackaged Windows apps by default

[MSLukeWest]

Description of Change

Right now, the Windows portion of a .NET Maui application is built as a packaged app. This will make it so newly created projects will be unpackaged by default.

The link pointed to in the comment (https://aka.ms/MauiTemplateUnpackaged) is temporary, we'll need to create a new help page for this.

[mattleibow]

Just a note that our template tests assume everything is a packaged app so we need to update them accordingly and make sure we are testing packaged apps.

Since the default and primary way was packaged, we need to probably make sure we have all of the tests like before, but now explicitly packaged.

[jfversluis]

Don't forget this new template?

https://github.com/dotnet/maui/blob/release/9.0.1xx-preview7/src/Templates/src/templates/maui-blazor-solution/MauiApp.1/MauiApp.1.csproj

[mattleibow]

Don't forget this new template?

https://github.com/dotnet/maui/blob/release/9.0.1xx-preview7/src/Templates/src/templates/maui-blazor-solution/MauiApp.1/MauiApp.1.csproj

Wow, thanks for catching that!

[MartyIX]

BTW: We tried to migrate to the unpackaged mode as well but we reverted back to the packaged mode. The reason was that in unpackaged apps, one cannot use file pickers under admin accounts (an exception is thrown). I mention it here just as a warning what this entails.

For more details, #20830 which mentions the underlying issue microsoft/WindowsAppSDK#2504.

[jonathanpeppers]

^^ I ran into the above issue as well, a long time ago with this app:

• https://github.com/jonathanpeppers/inclusive-code-reviews-ml/tree/main/Maui/MLTrainer

We were just trying to use unpackaged mode to simplify sharing the app in a .zip file.

[dotMorten]

This change worries me. Thinks like app redirection that is required for oauth authentication, or application settings and secure storage won't work in unpackaged, just to mention a couple. @MartyIX points out another issue.

[AathifMahir]

I really concerned about this decision, Using Unpackaged by Default does comes with lots of limitations and mostly new devs that coming from other cross platform mobile app Frameworks won't understand why most of the API's don't work on Windows when it is UnPackaged.

[Sergio0694]

When I saw the link to the PR I thought (and hoped) it would still a draft and that we could have a nice discussion before it went through. I'm really concerned by this change, for several reasons:

• The motivation is still not clear, nor the benefits
• Literally who asked for this?
• Several APIs will stop working completely when running unpackaged. This both introduces inconsistencies when testing a local build vs release one, and it will also just cause problems for people trying to just ship the app.
• This is also dropping a ton of benefits entirely that MSIX brings, such as app identity, clean uninstall, virtualization, easy support for running in AppContainer, etc.

I'm personally concerned with respect to the last point in particular. Especially with the recent push for "security above all else", how does that fit in with this change effectively pushing developers further away from AppContainer and from running in a sandboxed environment?

The change I'd have liked to see would've been to enable AppContainer by default. I understand that might've introduced friction, and just leaving full trust MSIX could've been a good enough compromise for now. But this is just the complete opposite end of the spectrum and makes all app not just always run as full trust, but without even a package nor the minimal virtualization that MSIX provides by default for Centennial (Win32) apps 🥲

[Redth]

@Sergio0694 hey let's have a chat soon with @BethMassi about this?

There's a few reasons motivating the change for us, some already mentioned, but worth repeating too...

1. There's really no way to dotnet run a packaged windows app, and as we had added support for .NET MAUI apps in VSCode, unpackaged was a way to help bridge this gap.
2. Dealing with certificates and installing ad-hoc builds is hugely frustrating to developers (eg: really hard to distribute a test build that's easily installed and run)
3. Inner dev loop - it's just slower to build the package and run it between changes while debugging apps.

In most cases we do work around the differences between packaged/unpackaged in the MAUI abstraction layer, however, yes there will definitely be cases that will be incompatible with packaged. As @BretJohnson mentioned, there's nothing stopping developers from switching to use packaged if they like (even if they choose to for a Release build for example), however I do agree, in some cases the difference in behaviours is not that intuitive between packaged and unpackaged.

It would be great to have a conversation about how WindowsAppSDK might be able to help improve packaged app scenarios to help with some of these pain points which have led us down this path to begin with :)

[Sergio0694]

Would love that, and if we can improve the tooling and the dev experience for everyone, that'd be awesome 😄

[BretJohnson]

I will add that Miguel Ramos said what's below about unpackaged being the default 2.5 years ago, back when he was the WinUI PM (this is from an email thread on the subject). Though at the time (1.1) unpackaged support wasn't ready yet - there were too many issues. I can forward the thread to MS internals who are interested - just holler.

In terms of improving the dev inner loop, being unpackaged (no-MSIX) is the best option. It saves build time, and devs have an experience similar to WPF/WF. However, WinUI3 wasn’t still yet, perhaps we will by 1.2. This should be the default experience.

[BethMassi]

In addition to the hurdles @Redth points out, just want to add here that we made this change intentionally, with a lot of discussion, and most importantly telemetry data to back it up. There is an extremely high rate of deployment failures in our new user retention data funnel. Since Windows is the default deploy target for MAUI, the top error (by far) is the device doesn't have developer mode enabled. Many users cannot enable this because of locked down environments. This change to the new project template for .NET 9 is documented (or it will be, I'll check on the state of the updates to the docs) and we added a property on the project properties page to toggle this easily in VS. This doesn't change existing projects.

This also doesn't change the publishing tooling at all (it still only supports packaged) even though an overwhelming number of our users ask for unpackaged app deployments. Our users want the same experience as WPF/WinForms and have been asking for this for years. Currently users can only publish unpackaged apps on the command line (with workarounds) because of WinAppSDK bugs. Also adding @MSLukeWest who is looking into working around these for tooling.