New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feat] Windows - Build MSIX Packages to Support Package Extensions #4818
Comments
Maybe we can do that as part of the NSIS implementation. |
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. |
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. |
I leave this issue open for msix but there is already an issue for deep linking here #323 |
When I submitted the 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 |
@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:
If you are only publishing to the Microsoft Store, choose the first option and submit an unsigned package created using the The package I submitted has been uploaded and approved. I will write an article later on how I submitted a |
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. |
@eythaann Hi, you can check this, https://gezihuzi.github.io/2024/04/05/publish-tauri-app-to-ms-store.html |
非常感谢! |
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:
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:
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 ❌:
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.
The text was updated successfully, but these errors were encountered: