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. ... View more

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 ... View more

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. ... View more

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

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. ... View more

Unfortunately, some existing software for which source code is not available that we want to package as MSIX uses "short-names" (e.g. "Progra~1") in some of their file requests.  When running this app, it is necessary for the app to find a crucial file that exists in the package by using the short-name, and this is an issue.  But a small change in the AppInstaller could resolve many of these issues.   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). ... View more

File Exclusions Completely in every packaging. Example uninstall.exe or uninstall.dat. Because so I won't have to manually edit appxmanifest and assets.  ... View more

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. ... View more

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. ... View more

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

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

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... ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

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. ... View more

Bumping this thread to ideas section for @John Vintzel    https://techcommunity.microsoft.com/t5/msix-packaging-and-tools/msix-packaging-tool-missing-file-type-associations/m-p/1834735#M936 ... View more

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? ... View more