API spec document for msix packaging in winappsdk

[sreading-MSFT]

API spec document for msix packaging in winappsdk

A microsoft employee must use /azp run to validate using the pipelines below.

WARNING:
Comments made by azure-pipelines bot maybe inaccurate.
Please see pipeline link to verify that the build is being ran.

For status checks on the develop branch, please use TransportPackage-Foundation-PR
(https://microsoft.visualstudio.com/ProjectReunion/_build?definitionId=81063&_a=summary)
and run the build against your PR branch with the default parameters.

For status checks on the main branch, please use microsoft.ProjectReunion
(https://dev.azure.com/ms/ProjectReunion/_build?definitionId=391&_a=summary)
and run the build against your PR branch with the default parameters.

[DrusTheAxe]

msix-packaging's makemsix has a bundle command but it does nothing?

[sreading-MSFT]

Well, I spell it out more clearly later, maybe this is overstating the issue. Only flat bundles are supported. Maybe that's what everyone uses now? The failure when trying to create a non-flat bundle is definitely not well documented by the tool, it's just an E_NOTIMPL failure in code that gets ignored and then the user sees a failure message "The bundle must contain at least one app package targeting a known processor architecture." because it never actually processed any of the payload packages:
https://github.com/microsoft/msix-packaging/blob/master/src/msix/pack/AppxBundleWriter.cpp#L117

[wjk]

Why, exactly, are full MSIX bundles not supported here? This makes it impossible to offer a single file to download containing every architecture supported by the application, or to deploy the App SDK runtime MSIX package alongside an application that uses it, which is rather important.

As an aside, as far as I am concerned, MSIX is a useless technology outside of the Windows Store. The code signing requirement makes it impossible for solo developers like me to distribute MSIX packages outside of the Windows Store (because, no, I cannot “just” purchase a certificate because they are so expensive, not to mention the fact that I would have to form an LLC before the CAs would sell me one because non-EV code-signing certificates are for some reason not available). Furthermore, it is impossible for an MSIX packaged application to be installed for all users on a computer, like all other Windows software (and, no, provisioning the package for all users is not an option because [a] there is no way to do it outside of manual PowerShell commands and [b] if the user were to delete the MSIX file after installing it, which would be a logical thing for them to do, the provisioning operation would then fail). And even then it is far too easy to accidentally uninstall the program, after which it will not be re-provisioned.

As much as I support the Windows Store — and I support it a lot — it is not a useful distribution method for serious applications. Since Microsoft has killed off the Store for Business, it is now impossible to download an app except by tying it to an individual’s consumer Microsoft account. Worse, the Windows.Services.Store API is a complete joke. There is no way to debug the use of these APIs without completing and publishing your application, having it go through App Review — and then you have to buy a copy of your own app with your own credit card (and this is somehow a deliberate design decision). I always liked the older Windows.ApplicationModel.Store API because it is very easy to test through the use of the CurrentAppSimulator class. However, that API requires CoreWindow, which is now very deprecated. As a result, developers who distribute their apps on the Windows Store have to handle their own billing and licensing, which negates the main advantage of a centralized app store. Payments should be handled by the platform.

[DrusTheAxe]

Why, exactly, are full MSIX bundles not supported here?

We're lighting up some new functionality and there's no change to bundles needed for it, hence the reason it's out of scope for this tool at this time. While I'd like to see this tool expand to encompass more functionality in time (including bundles) there's only so many hours in a day and you've gotta crawl before you walk before you run. So our focus here is on gaps current tools don't address.

Existing tools will continue to work just fine for bundles e.g. makeappx.exe. If there's issues or enhancements you'd like to see addressed please file an Issue so we can track the ask and get it onto our radar. Thank you.

[DrusTheAxe]

The code signing requirement

Are you aware of AddPackageOptions.AllowUnsigned?

If you make an unsigned package (i.e. just run makeappx.exe, no signtool.exe) you can install it via PackageManager.AddPackageByUriAsync introduced in 10.0.19041.0 (aka 20H1) e.g.

packageManager.AddPackageByUriAsync("file://c:/foo/bar.msix", new AddPackageOptions(){ AllowUnsigned=true })

You can also accomplish this via the Powershell cmdlet Add-AppxPackage -AllowUnsigned ...

no, provisioning the package for all users is not an option because [a] there is no way to do it outside of manual PowerShell commands

There are multiple ways I'm aware of you can provision a package

1. PackageManager.ProvisionPackageForAllUsersAsync()
2. Powershell cmdlet Add-AppxProvisionedPackage
3. DISM.exe /Add-ProvisionedAppxPackage
4. Intune
5. MSIX Hero

To name a few. There's probably other ways out there than I know :-)

Provisioning a package affects more than just the current user so provisioning (regardless of how) requires the caller have admin privilege. The Remarks section on the ProvisionPackageForAllUsersAsync() page has more details.

[b] if the user were to delete the MSIX file after installing it...the provisioning operation would then fail)

This is not how provisioning works. When you provision a package it's staged on the system e.g. C:\Program Files\WindowsApps\LolzCatzVidz_1.2.3.4_x64__1234567890abc\.... That's locked down and managed by the Deployment stack; a normal user can't delete that (and if you're elevated you've already pwned the system).

Once you've successfully provisioned a package the package source is no longer needed. If you provisioned a package with a file: URL using a physically local .msix file then you can delete the .msix file and it doesn't matter. The package directory (C:\Program Files\WindowsApps\...) is unaffected. Likewise if you provisioned a package with an http: or other network URL once provisioned you don't need network connectivity to that source to use the provisioned package.

And even then it is far too easy to accidentally uninstall the program, after which it will not be re-provisioned.

To be pedantic, when you login after packages are provisioned packages (or a user's 1st login) all provisioned packages are registered for they user. The user can "uninstall" the package but that's just deregistering it for the user. The package is still present on the system (you have to deregister a package for all users AND deprovision the package to actually remove it from the system). If the user e.g. right-clicks on a provisioned package like Calculator and says Uninstall the package is deregistered for the user (StartMenu items, file type associations, etc all gone). After all the user is in control of their experience. Do you find this user experience is "too easy"? In what ways?

This is well off the beaten path for this PR so if you have additional feedback or questions please create an Issue or Discussion for follow up. Thank you.

[DrusTheAxe]

Missing property?

enum MountableImageFormat
{
    Auto,
    CIM,
    VHD,
    VHDX,
}
MoutableImageFormat Format;

see earlier comment

[sreading-MSFT]

Still not sure of benefit of this vs using file extensions. Not opposed, just not sure who wouldnt use Auto.

[sreading-MSFT]

@microsoft-github-policy-service agree company="Microsoft"

---

In reply to: 1472758116

[mominshaikhdevs]

@sreading-MSFT whats the latest update on this?