MSIX feedback Ideas

Packaging in Windows Sandbox

brt_1978 — Mon, 07 Jul 2025 14:39:42 GMT

Would it be possible to use the MSIX packaging tool inside Windows Sandbox?

I tried installing it and after opening it complains about the driver not being installed.

It probably goes against the ideas of WSB, but an installation also would need to survive reboots which isn't an option currently in WSB.

Configurable breakaway for MSIX packages in app manifest

mattplan8 — Thu, 07 Dec 2023 17:29:27 GMT

I've run into several applications that have child processes that when packaged in MSIX will cause the child process to break out of the container and then fail.

This is rather inconvenient as it's not normally obvious that some features of an app aren't working when they rely on a child process for the functionality.

This can be worked around with a wrapper script/exe that executes the main process with invoke-commandindesktop -preventbreakaway but it would be ideal if you could simply define the breakaway behavior in the app manifest.

Participate in Our MSIX Survey - Shape the Future!

Sushant_Bansal — Mon, 07 Aug 2023 07:01:03 GMT

Hello MSIX community!
We need your help to make the MSIX platform better for you! Take part in our quick and valuable survey to share your thoughts and help shape the future of MSIX.

Your Voice Matters:
Your feedback will directly impact our direction and feature priorities.

Get Started:
Take the survey here: Survey Link

Have Questions?
Reach out to us at msixperts@microsoft.com for assistance.

Learn More:
MSIX Packaging: Learn More
AVD App Attach: Learn More

Thank you for being part of the MSIX community! Together, let's shape the future of MSIX.

Best regards,
The MSIX Platform Team

Create AVD App Attach ready apps and publish from within Visual Studio

Sushant_Bansal — Tue, 13 Jun 2023 10:05:43 GMT

Visual Studio offers the Windows developers an integrated workflow to easily create MSIX packages from within their development environment.

But creating an App Attach ready app is a long process, and it is even more complicated to further publish it to AVD.

Recommendation:

To enable developers to create and test AVD App Attach ready apps, and publish from within their Visual Studio development environment.

Include in MSIX like App-V

santhoshskb — Thu, 25 May 2023 16:21:51 GMT

Similar to App-V , Please create MachineScript feature which enables to run scripts with elevated privileges. if already present please guide me

Merge/Override File/Folders and Registry

SajidRavat — Thu, 06 Apr 2023 14:13:42 GMT

This feature was available in App-V and would be great in MSIX to hide locally installed apps when required. Java runtime springs to mind.

MSIX Package Shortnames

TIMOTHY_MANGAN — Thu, 02 Mar 2023 14:35:55 GMT

When AppInstaller lays down the package under WindowsApps, it creates folders and files as needed. The package format does not contain any short-names, and what happens is that created folders get their typical short-name generated on disk using the normal formula (first match gets ~1, second ~2, etc). However, the file portion does not get a short-name written. This should be automatic.

Yes I'm aware that we could get mis-ordering of the ~#'s (a problem best solved the way App-V did it by generating unique short-names at packaging and bring those along in the package), but just getting AppInstaller to generate the short-names on those files would be helpful and likely solve compatibility for several vendor apps (often, the short-name request happen due to COM).

File Exclusions Completely in every packaging

atplsx — Thu, 02 Mar 2023 13:41:14 GMT

File Exclusions Completely in every packaging. Example uninstall.exe or uninstall.dat.

Because so I won't have to manually edit appxmanifest and assets.

Allow Windows Features to be specified as Dependencies and enable them during the installation

ThomasDanecker — Mon, 09 May 2022 00:02:40 GMT

Our application relies on an optional windows feature, in our case Projected File System (Client-ProjFS).

It would be great if we could specify those as dependencies in the installer and have the installer enable them.

Working around that is very cumbersome at the moment. We couldn't get custom install actions to work as those only seem to be supported for games.

MSIX AppAttach Support within Endpoint Configuration Manager

CraigDK — Wed, 02 Feb 2022 10:43:21 GMT

MSIX AppAttach support so far has only made its way to Azure Virtual Desktop.

There would be benefit for organisations using MECM and on premise VDI solutions if MECM had support for MSIX AppAttach.

This would improve the delivery time in MSIX applications to users of those non persistent VDI's as MECM would not need to download the software first and reduce storage requirements as apps can be hosted on and stream from a DP rather than consume storage on a VDI's differencing disk.

Plugin for Visual Studio Code for creating the Appxmanifest.xml with syntax support.

peterfa2018 — Wed, 20 Oct 2021 05:24:06 GMT

Is there a plugin for Visual Studio code for creating the Appxmanifest.xml with syntax support. Or is something like this planned ?

Backward Compatibility and the AppXManifest Schema Sets

TIMOTHY_MANGAN — Wed, 08 Sep 2021 01:44:14 GMT

See original post: Backward Compatibility and the AppXManifest Schema Sets - Microsoft Tech Community

"Windows Application Project" to create MSIX in Visual Studio issues

TIMOTHY_MANGAN — Wed, 08 Sep 2021 01:38:27 GMT

See original post here: "Windows Application Project" to create MSIX in Visual Studio issues - Microsoft Tech Community

I was just asked to move this to the ideas section, however note that the original post is 9 months old so things have changed...

Idea: Control over child processes

TIMOTHY_MANGAN — Wed, 08 Sep 2021 01:33:59 GMT

There are times when integration is required and the container gets in the way. The upcoming Shared Package Containers will help when both parts are MSIX packages, but not so much when the secondary is not containerized.

In App-V this was solved by RunVirtual, a way to designate that a given process name should run inside a particular virtual environment. This would also work for MSIX, but I'd like to propose a different idea that likely would offer solutions to more kinds of problems with containerization and multiple applications.

What I would like is a new addition to the AppXManifest whereby I can list some named processes to be controlled. If a process is named, it would have one of two settings, marking the process to explicitly run inside or outside of the container. This list would only apply to new processes being started as a child process of a process already in the container.

The flexibility of this would be quite helpful as more apps move into the container.

AppInstaller Feature: Deprecated packages

TIMOTHY_MANGAN — Tue, 25 May 2021 14:57:58 GMT

IDEA: As packages get updated by a vendor, it will not always be the case that the replacement will be something with the same package family name with a different version:

Vendors sometimes update product names
Mergers occur
Code Signing Certificates expire and the new one might be different (for example the company changed locations so the new field in the subject for the town changed).

To handle these situations, perhaps appinstaller needs a new element to list deprecated packages that either must be or could be removed. If marked as must be, their would be an app removal of the old and adding of the new. If marked as could be, perhaps someone gets a notification that the old one could be removed as part of the installation.

Portal to check available MSIX applications from software vendors

rajeshsankar — Wed, 17 Feb 2021 10:49:21 GMT

It would be really great if there were a portal within Microsoft to check for applications from known software vendors that are already available in MSIX format.

Regarding Extensions in Schemas

TIMOTHY_MANGAN — Thu, 21 Jan 2021 22:28:00 GMT

I am grateful to see the response to the previous query looking for guidance on implementing Extensions in the AppXManifest, namely Extensions in the package manifest schema - Windows UWP applications | Microsoft Docs.

The concept of separation of app specific extensions versus package-level (applying to all apps in the package) might need a bit of tweaking, and thus tweaking of the supported element lists in that documentation.

While multi-application packages are one reason for package level extensions, another is package extensions that are (or could be) unrelated to a specific application. A key example would be in-process com extensions that are intended for applications outside of the package. Currently all com extensions must be placed under an Applications/Extension, and there is support for in-process COM dlls to be added as a Surrogate in the manifest, at least from a validation standpoint but they don't work. Shell Extensions are an example of this, where the explorer.exe process should integrate them

into the explorer process, but publishing in-process shell extensions for consumption by other application level processes not in the package has been traditionally supported.

So I believe the list of package level extensions should be extended, starting with the shell extensions. However, it is possible that Microsoft wants to support the concept of shell extensions without adding them directly into the explorer.exe process (for security issues). Which is OK, as long as we can get support for traditional shell extensions. In computing, it is really all about the data and end-users don't always start with the app, but the data file. Integrated shell commands are not enough, and shell extensions have been a long-standing solution. While some shell extensions have been migrated to independent Manifest elements for support, most have not. I believe Microsoft has some work to do here, and a roadmap (even without dates and just saying this is in or out of scope) will be helpful to developers WANTING to move their existing applications to MSIX.

Status of Shell Extensions like Context Menus

TIMOTHY_MANGAN — Mon, 04 Jan 2021 16:41:42 GMT

Shell Extensions, such as Context Menu Handlers have been sought after in MSIX for quite a while. While the Microsoft MSIX Packaging Tool does not support them (today), there is plenty of evidence from Microsoft that they should be possible.

In particular, I point to the following article:

Modernize existing desktop apps using Desktop Bridge - Windows applications | Microsoft Docs

which shows an example. (The example is clearly incorrect, as the Application element required an Id attribute and VisualElements subnode. While an older example, it is not deprecated and it is not uncommon for desktop bridge documentation to be referenced for MSIX, even if not perfect. Even through shell extensions don't necessarily tie to an exe inside the package when implemented as an in-process com object in the file explorer, we can usually find an application in the package to leverage to overcome this).

It does not seem possible to get this example (nor any other) to work. Can we get some feedback on the status of shell extensions? Is it that:

There are gaps in the documentation that need addressing but they work if specified correctly.
It is supposed to be working, but there are bugs in the implementation (AppInstaller and or runtime) that need fixing.
Microsoft is still working on a complete implementation and customers should be patient.
Microsoft has decided not to support the functionality going forward.

Missing file type associations

TIMOTHY_MANGAN — Fri, 30 Oct 2020 00:35:52 GMT

Bumping this thread to ideas section for jvintzel

https://techcommunity.microsoft.com/t5/msix-packaging-and-tools/msix-packaging-tool-missing-file-type-associations/m-p/1834735#M936

Version detail in .msix file properties

TIMOTHY_MANGAN — Thu, 29 Oct 2020 22:09:26 GMT

Wouldn't it be just awesome if we could right-click an msix/appx file, pick "properties" from the popup menu and see the version info? You know, just like winpe and msi files?

Perhaps this could be added to the file creation that makeappx does?