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

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

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

Hi, Currently MSIX Packaging Tool has a moving part wherein the MSIX Packaging driver installation is not part of the main MSIX Packaging Tool itself. Can this be made part of the Packaging Tool installation itself if someone were to install a standalone copy of the MSIX packaging Tool.   Thank You!   BR, DS   ... View more

Hello,   We have packaged a WPF app with MSIX and signed using a valid certificate (GlobalSign). It installs ok on Win10 and Win8.1 but not Win7 SP1. The error code is 0x8bad0042. Something wrong with the certificate...   We then tested with the (Microsoft) VLC test package on GitHub with same error on Win7 SP1.   The potential bug has been submitted to GitHub : https://github.com/microsoft/msix-packaging/issues/345 No answer yet :(   Any advice on how to troubleshoot this error ?   Really need some help, Thanks ! ... View more

Hi,  while installing msix is there any ways to pass user inputs in msix format. thanks vamshi ... View more

According to this Microsoft document to integrate with Office as a cloud provider you need to add a registry entry under HKEY_CURRENT_USER\Software\Microsoft\Office\Common\Cloud Storage.   This seems to not be possible at the moment for MSIX installed software. ... View more

We sign our MSIX packages with a USB dongle certificate, it would be nice if this option would be included. ... View more

I believe the template could be quite useful outside of the full command line form of repackaging.  As far as I can tell, there is no way to use the template outside of the command line interface..   I would like to launch the tool, select a template file which then pre-fills all of the information that would have been used in the command line, but still go through the wizard.  This would be very useful for repackaging an app that has regular updates but cannot be (easily) fully automated.     ... View more

Deploy a Windows10 MSIX Converter Client. This as catalog image in Azure ... View more

If re-packaging an app with multiple shortcuts, one of them becomes the default entrypoint to launch when the package is installed on end-user machines.  It isn't clear how that is selected, but it does look like the top one in the manifest is it.   While you can manually edit the manifest, we should prefer packagers not do that when possible.  Therefore a good solution to setting the default launch would be to provide a selection dialog in the "First launch tasks" dialog of the packaging tool.  Up/Down arrows would suffice. ... View more

<Separating out Ideas submissions with multiple items>   For the Packaging engineers, it will be a much helpful part if an optional Debug Shortcut (preferably a Command Prompt shortcut) option be provided (by default within the tool) Engineers can use this option to debug and identify cause for issues using ProcMon, RegMon etc. Once the Fix is developed, build the Final MSIX packaging with Fix by unselecting the Debug Shortcut option and release the Final build for end users ... View more

<Separating out Ideas submissions with multiple items>   Check with relevant teams if the definition for “Reset” option under “Apps & features” in Windows setting can be rephrased as the statement “Application will be re-installed” is not in-line with the actions performed in the background on selection of this option ... View more

If you run an MSIX file of an already installed package, the only available button is the "Launch" button.   In MSI world, running an .MSI file of an already installed setup provides options for repairing and uninstalling. I would expect the same set of options to be available in the MSIX app installer, possibly in a dropdown menu in the right bottom corner (three dots or a gear icon). This would make some quick MSIX tests faster (no need to dig through Start menu or Programs section if you are just playing with a particular MSIX file) and - as outlined before - it would make it a bit more consistent with the Windows Installer behavior. ... View more