<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

Currently, there is no way to extend the original application by for example adjusting the shortcut parameters or changing the application to target PSF launcher to inject custom fixups and other stuff. Ability to override the original shortcut would be required for IT Pros using Modification Packages to deploy and customize their software.   Use case: MSIX package is available as an official installation media from the software vendor Enterprise would like to customize the app by calling some first-launch-configuration script, or injecting a custom logic to be executed The proper place for both would be to use PSF framework by re-targeting the original shortcut to the launcher, and have JSON file do the rest. The above may be achieved only if the original package uses PSF. In this case, the user can try to override the original JSON file so that it gets applied instead. However vendor packages will only use the PSF in case of known compatibilities which were not resolved in code, so it is very likely that the package does not use PSF Launcher. As a result, the author of the Modification Package is unable to achieve the above, because at the moment MP do not provide any kind of functionality of overriding the original shortcut (they have no entry points as a matter of fact). The workaround is to repackage the original MSIX, add any existing modifications and re-save it using own signature. This on the other hand breaks the identity and future updates. The suggestion is to implement a possibility to define entry points, which - in case of modification packages - override the base ones. ... View more

  In 9/10 cases, the DEV environment or the MSIX packaging tool will be setup in the customer environment Provided an option under Settings menu to have a Standard certificate selected (which would remain persistent unless engineer changes) reduces one step in the process ... View more

Its common for exisitng installers to require a reboot.  The MSIX Packaging Tool should be able to convert these apps. ... 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

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

Dear Sirs.   May Developers as me, are using VMWARE Workstation instead of Hyper-V in their development machines. I think It is very important to have ability to use MSIX tool in that configuration. As Hyper-V and VMWARE can't so exist, it is one more reason to support it.   Also VMWARE Support snapshots, and in complex installation scenarios it is possible: 1) Take a snapshot before installation 2) Install software, (as many step as necessary) 3) Take a snapshot again after installation and compare it to initial state   So, we have all data to make installation package.     Thank you,     ... View more

In order to easily debug packages, support for launching a non-package executable inside the package container is needed.  In App-V there are two methods to do this, either of which could be adopted: A PowerShell cmdlet like Start-AppVVirtualProcess A command line switch like /appvve PowerShell would be the preferred method.  We could specify the package name to identify the container to run in.   This would allow us to debug in scenarios such as: Launching a local PsfLauncherXX.exe with local config.json & tracefixup.dll to enable monitoring of a package without having to repackage.  Similarly to test a potential fixup fixup dll prior to repackaging. Launching a tool like Regedit so as to see the registry the same as what the application would see. ... View more

At the present time, MSIX is blocking access to TPM (for both Reading from TPM and Writing to TPM)   Examples why access to TPM is required:   1. If you were to package a browser using MSIX and then need to authenticate to a corporate Web Site or SaaS application with a Virtual SmartCard (VSC)or X.509 certificate that is stored on TPM,  authentication fails as MSIX application cannot read from TPM.   2. If a corporation provides a Win32 application to assist user in obtaining a X.509 Certificate / Virtual SmartCard (VSC) and packages with MSIX .... then when the application reaches the point to Write the certificate to TPM.  ... View more

My packaging standards usually involve scripted installs, both a pre-monitor script and another for the application installation.   The pre-monitor script will install application dependencies and then perform a flush of the NGEN queues to ensure that ngen compilation for dependencies (or OS crap in general) is not accidentally caught in the monitoring.   In the portion of the Packaging Tool where existing windows services that are best practice to stop/disable are detected, it would make sense to also flush the ngen queues.   On Win 10 there are up to two ngen queues to worry about, both x86 and x64 (C:\Windows\Microsoft.Net\Framework[64]\v4.0.*\ngen.exe).  The queues can be queried and if needed flushed using ngen.exe EXECUTEQUEUEDITEMS.   Bonus points if you also flush the queues at the end of monitoring as to capture native interface files for the application being packaged. (I am told that as long as we are distributing to the same "architecture" this is OK.  In this case "architecture" means within the Intel/amd x86/x64 family and not ARM.  And I think that MSIX is similarly restricted anyway.)     ... 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

10/12/2018 Proposal for a MSIX Packaging Tool “Plug-In” Strategy Tim Mangan     Purpose The purpose of this idea is to describe a proposal to extend the capabilities of the MSIX Packaging Tool by allowing for vender specific plugins to enhance the packaging experience. Relevant examples of the need It is very clear that, with the current packaging tool, Microsoft is handling only the most basic needs of IT Pro application packaging for MSIX, and ceding the hard work to partner built tooling. In some cases, we are likely to see vender driven solutions that either completely obliviate the need for the Packaging Tool (replacing it with their own complete functionality) or providing a post processing tool that picks up where the tool leaves off. This is not unlike the situation with Microsoft App-V packaging where some vendors provide an independent way to create a package; some put a front-end wrapper around the sequencer (command line interface), and my own work in post process analysis and modifications.  I would have loved to be able to launch such work from the “sequencer editor” directly via a plug-in model rather than a complete post-process command after the package was completed. How it might work The vendor would probably create a modification package (aka add-in) for the Packaging tool. The add-in would be a dll written in a form designated by Microsoft. I’m assuming (without checking) that the tool is actually a MSIX package itself, and that it is written as a WPF app, indicating that the plug-in would want to be similarly structured (although I suppose PIO to an unmanaged dll might be possible too). Microsoft will designate where the plugin is to be placed and if any registry entries are needed to register it (or if file placement alone is sufficient). The plugin would need two designated interface calls. A call the tool would make early on after discovering the plug-in. The tool would return a text string and a callback function.  The text string would be used to provide ui access to the plugin, possibly in the form on a button generated at runtime by the packaging tool. An example of possible placement of the button would be next to the “Package Editor” button and the end of the capture wizard, but other workflows would need to be considered as well. The callback function would be executed by the tool when requested by the end-user. The tool would pass relevant information to the tool. We’ll have to wait for Microsoft to designate what that is, but basically it is likely to include a reference to the AppXManifest file, registry.dat file,  and “ingredient list”. The plug-in callback function could perform analysis, pop-up it’s own dialogs to display recommendations and/or make changes to the manifest and ingredients. Microsoft may need to provide guidance on what certain explicit types of changes that are or are not supported. When the plug-in callback function returns, the tool would accept the changes (possibly after some validation) and allow further access to the package editor or other vendor plug-ins as appropriate. Conclusion The current process of producing production ready packages using the Packaging Tool for the typical inventory of applications I see currently in use by the Enterprise customers I work with is too much work.  Partners can improve this, but I feel it would be best to have one "tool chain" that can include the best of what Microsoft has to offer plus the specialty improvements that can be offered by partners.   I hope this can become reality!   ... 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