Skip to content
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

Distinguish between MSIX installed from windows app store or a url #4993

Open
vmiguelangmsft opened this issue Dec 20, 2024 · 1 comment
Open

Comments

@vmiguelangmsft
Copy link

Hey everyone,

I'm working on a project where I have an MSIX package that can be installed either through the Windows Store or by downloading the package directly from a website. I'm having a bit of a hard time figuring out how to distinguish between the two installation methods.

I've tried checking the installation paths and the PublisherId using the Windows.ApplicationModel.Package class, but both methods show similar values for installations from both sources.

@DrusTheAxe
Copy link
Member

an MSIX package that can be installed either through the Windows Store or by downloading the package directly from a website. I'm having a bit of a hard time figuring out how to distinguish between the two installation methods.

It sounds like you're trying to determine where a package installed on the system came from?

Why do you ask?

There's Package.SourceUriSchemeName but that really only tells you if the package came from a local or network source (ish, e.g. install q:\foo\bar.msix will report SourceUriSchemeName=file even if Q: is a network file share).

You seem to think the distribution source and installation mechanism(s) are significant. Why?

A signed MSIX package has an identity unique across space and time and corresponding to an exact set of bits. How those bits get to the machine doesn't alter the bits, or identity. If you have the Store sign a package it could be distributed and ultimately installed by many paths and mechanisms. Store, website, Intune, winget, OS update, USB flash key or other forms of sneakernet :-)... These and more are merely paths between the source of a signed package and the installed package.

'Tis not the journey that matters but the destination.

If you submit the Foo package to the Store it doesn't matter if Store installs v1, winget updates to v2, Intune updates to v3, user downloads v4 from a webserver and installs via AppInstaller app, you upgrade Windows and the OS updates to v5, ... or any other permutation of actors.

Signed MSIX packages have a strong (cryptographically verifiable) identity that's unique across space and time, and corresponds to a unique set of bits. If even 1 bit is changed the identity needs to differ (e.g. v1.2.3.4 vs v1.2.3.5) so a specific package (e.g. Foo_1.2.3.4_x64__1234567890abc) is always the same thing, regardless which path the bits take to reach the machine or who was holding the lever initiating the install. If you install a package from Store and then try to install the same package from your web server it'll have the same identity and fail the 2nd install (ERROR_PACKAGE_ALREADY_EXISTS).

We log inputs to an install for troubleshooting, but that has no bearing on the end installed package. Regardless the distribution technologies and installation actors, the package is the package. Thus there's no API to determine "What journey did package X take to reach this machine?" as there's no meaningful answer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants