Discussion: Adding support for new features to MSIX manifests

[wjk]

Discussion: Adding support for new features to MSIX manifests

Currently, only Microsoft can add new features to the MSIX manifest schema, through extending the code and data inside AppxPackaging.dll. However, some users have asked for MSIX to be able to install more esoteric payloads, such as MMC snapins or Windows credential providers. Currently, the only way one could try to do this is to use customInstallActions and pack an MSI into the MSIX package. While this would work (assuming App Installer permits installation of apps that declare that rescap, which I am unsure of), IMO it goes against the design of MSIX. Furthermore, waiting for Microsoft to add new features into Windows core goes against the spirit of Project Reunion. 😄

One way new features in MSIX could be implemented in a backwards-compatible way would be to to invent a namespace not natively supported by Windows, and put custom features into that. Then users would add its prefix into IgnorableNamespaces so that Windows doesn’t complain about not recognizing it. Finally, the app would bundle a small component run using customInstallActions that parses the manifest file and processes the elements during the installation process. This small component should be extensible, so that third parties can add support for their specific needs by writing a plugin DLL, instead of having to fork and vendor the entire tool.

I have a good enough grasp of this process to start on a preliminary implementation in my own repo, but I don’t yet have enough detail for a formal Feature Proposal just yet.

[jonwis]

Check out https://github.com/microsoft/msix-packaging - that's a great repo in which to try out some of these ideas before integrating into the overall product package manager.

What would you want to see in a Reunion-style package manager?

Your observation is correct - MSIX ensures that no (or very little, tightly controlled) app code is run during install and uninstall. Those are tricky times and it's challenging to write code that runs correctly on half-staged / broken-needs-repair / being-uninstalled, along with the testing on all the various variants of systems.

MSI's custom actions ended up being very attractive and people built entire "sub installers" based on them.

What would be some rules for the kinds of code that apps can run during install & uninstall?

[wjk]

I’m not proposing that I add arbitrary code to run during install/uninstall; the use of customInstallActions is simply a necessary reality given how today’s system MSIX support is written. All the logic would be put in the AppxManifest.xml file, just as we do today for MS-supported installation features. I actually really like the design of MSIX as it is currently designed, including the declarative installation system; I just know that IT admins have been saying they want to make it able to install more kinds of software than it can today. (There was a post in the MSIX techcommunity outlining this issue, but I cannot seem to find it right now. I do remember it specified MMC and credential providers specifically, which is why I mentioned those in the OP.)

I understand that msix-packaging includes support for packing and unpacking MSIX files; it also includes MsixCore for use on downlevel OSes. However, MsixCore does not work on Windows 10 (it is programmed to always delegate to the OS if running on a recent enough build), so adding features there would seem to be a non-starter. How do you suggest I work on this, beyond simply opening design issues there? If that means forking MsixCore to make it work on Windows 10 and then support a superset of what AppxPackaging does, that’s fine by me. Thanks!

[aclinick-zz]

as the pm who put custom actions in MSI i can tell you it didn't work out how the 29 year old me expected :)

IT admins can run scripts with MSIX using the Package Support Framework (PSF) https://github.com/microsoft/MSIX-PackageSupportFramework/tree/master/samples/PSFScriptingSample allows you to run a Powershell onFirstRun, Run and exit

I would look at the PSFbut also feel free to provide feedback/code to MSIX Core so that we can determine how best to undock MSIX for you to use with Reunion

[stevewri]

What are the next steps here? @wjk - were you planning to try out some ideas with the packaging repo @jonwis pointed to and submit a formal proposal, or work with MSIX Core per @aclinick's suggestion?

[wjk]

@stevewri Unfortunately, I don't quite understand what you’re asking. As I said above, the MSIX Core repo doesn't have the ability to change the OS implementation of the MSIX packager AFAIK. The package-support framework won’t work for my needs either. While I can run code on first-run to modify the system as needed, there is no way to ensure that the changes are then cleaned up on uninstall, as PSF only supports code running when the application exits. Dangling references to package files will still be a problem, as described in #97.

However, the implementation I described in the OP probably won’t work, as I remember reading somewhere that the customInstallActions rescap is protected by the system. Only apps specially blessed by Microsoft can successfully use it; random sideloaded packages will not install if they declare this capability. If I am mistaken here, I’d be glad to hear it. Thanks!

[jonwis]

You're correct, customInstallActions requires a specific capability and approval as it explicitly breaks the "MSIX install/uninstall are programmatically driven" proposition.

The packaging system can trigger a background task when your app has been updated. Maybe we could define another background task - "you're being uninstalled" - that would let you do your cleanup? The main issue we have is preventing unbounded/uncontrolled work in servicing operations - Contoso shouldn't be able to camp in their background task for 20m and use that time to beg the user to cancel/reinstall.

For now, can you enumerate the features you'd want to see? The packaging team (hi @jvintzel and @aclinick !) monitors these threads and we're always looking for ways to make MSIX more useful, even if we can't deliver that as part of Project Reunion directly (yet.) :)