[feat] Windows - Build MSIX Packages to Support Package Extensions

[madaster97]

Describe the problem

There are a number of windows features that require a desktop app to have package identity. For example, you can use a package extension to have websites redirect to your desktop application (app URI handlers) similar to universal links on iOS.

The issue is that Tauri apps build to msi which cannot have package identity, so we can't use the features above in our apps. We'd need to build to MSIX to do this.

Describe the solution you'd like

Enabling Package Extensions from Config

If we implemented package identity under the hood (as in, build msix packages), then it'd be great to give config options for some useful package extensions, such as windows.appUriHandler. This would for instance increase OAuth 2.0 support in Tauri, since we'd have a method other than custom URI schemes or localhost servers to accept OAuth 2.0 requests from the system default browser. Discord thread for reference.

Option for Package Identity: Sparse Package

Microsoft outlines 2 ways to obtain package identity:

• Build MSIX directly from your source code (discussed as an alternative below)
• Build a sparse package, which notably is ⚠ only supported in Windows 10 version 2004 and later

A sparse package effectively sits beside your existing apps and adds additional features using an MSIX that points at your existing MSI based app. It seems like a much lower lift than building MSIX from source, for some reasons discussed in the alternatives section below.

Microsoft has a nice tutorial outlining how to generate a sparse package, and here's where I expect the complexity to be for Tauri:

• The additional build step includes signing the package. We'd need a system for choosing/generating a certificate to sign the package with
• There is a run-time registration step we'd need to introduce. I'm not actually sure if this goes in the MSI or MSIX 🤷‍♂️. That tutorial includes a code snippet, and WiX has some documentation on injecting the action with a template. We'd just need to write a dll for this and include it in the %AppData%\Local\tauri\WixTools folder (I think)

Alternatives considered

Creating full MSIX packages instead of or in addition to MSI. This is nice because it's supported before ✔Windows 10 version 2004, but has a couple big drawbacks ❌:

• Wix doesn't currently support MSIX, so we'd have to re-tool to one of the techniques in the link above
• There are a ton of prereqs Tauri would need to meet in terms of what windows features it uses (example: Using a background task instead of a windows service)
• [ ] I would appreciate if someone could review the prereqs list

Additional context

I researched this because it's important for flexibility in using Tauri as an OAuth 2.0 client app. In issue 323 I saw some confusion on this and wanted to call out based on RFC 8252 section 8.12 you shouldn't be conducting OAuth 2.0 from a web-view. Instead, you should be launching to the system default browser and having it redirect back to the initial native app. Adding app URI Handler support would be a great way for Tauri apps to conduct this redirect.

[lucasfernog]

Maybe we can do that as part of the NSIS implementation.

[amrbashir]

I have plans to make a MSIX bundle for tauri but probably in v3 (unless someone else wants to do it before that).

If you just want to have deep-link, then we can add it for both WiX and NSIS once #4674 is merged.

[madaster97]

Thanks both!

@amrbashir - Yeah getting a custom URI scheme with WiX or NSIS would be great. I see that sticking around for some time, precisely because people won't have to deal with MSIX files.

[amrbashir]

I leave this issue open for msix but there is already an issue for deep linking here #323

[gezihuzi]

When I submitted the msi application generated by Tauri to the Microsoft Store, I received the following message:

If your EXE or MSI cannot comply with Microsoft Store policy 10.2.9, you can consider repackaging your existing EXE or MSI to MSIX format. Microsoft Store offers many complimentary benefits for MSIX format such as code signing, hosting etc. For more details, click here.

You can run your EXE or MSI installers through MSIX Packaging Tool and obtain an MSIX package that you can submit to the Microsoft Store as MSIX packaged app. Note that you have to delete your app name from existing Win32 app in Partner Center in case you want to use the same for MSIX packaged app.

---

I manually converted the msi package to an msix installation package using the MSIX Packaging Tool. I will try to submit this content to the Microsoft Store and provide updates on progress.

[eythaann]

@gezihuzi Hi, I want to do the same, do you need to sign the msix or can I upload it to MS Store without sign it? I read that Microsoft sign the msix installers on the store but to upload it for review it stills need to be signed.

[gezihuzi]

@gezihuzi Hi, I want to do the same, do you need to sign the msix or can I upload it to MS Store without sign it? I read that Microsoft sign the msix installers on the store but to upload it for review it stills need to be signed.

To my knowledge, there are currently two options for creating products in the Microsoft Store:

1. MSIX and PWA, MSIX supports packages uploaded without requiring signing, as Microsoft Store automatically signs them.

2. EXE and MSI, which require purchasing a certificate for signing.

If you are only publishing to the Microsoft Store, choose the first option and submit an unsigned package created using the MSIX Packaging Tool.

---

The package I submitted has been uploaded and approved. I will write an article later on how I submitted a Tauri app to the Microsoft Store.

[eythaann]

Cool I did the same, now I'm waiting for certification or approval. And yes an article sounds great currently there are no articles or something talking about msix with tauri.