Currently there is no convenient way for end end user who has purchased software from an ISV to install a side-loaded MSIX package machine-wide (for all users). Software is often licensed on a per-machine basis and not tied to a specific user. Non-technical users should be able to double-click on an MSIX package and have it installed machine-wide if the vendor has configured it to do so.   Perhaps there are other ways to accomplish this, but here is a suggestion.   Introduce an 'AllUsers' restricted capability to the appxmanifest file that flags the package so that when a user double-clicks the package to install it, it gets provisioned for all users (naturally would require specifying allowElevation in the manifest as well). Similarly, any user who tries to uninstall the package should get prompted for elevated privileges - once elevated, the uninstall should uninstall for all users.   Without this ability, I can't see how MSIX will replace MSI in the long term. ... 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

<Separating out Ideas submissions with multiple items>   Being aware of Shortcut management support to be included in upcoming release, will look forward to see the following supported in future releases It will be helpful to address customer requirements in enterprise domain if advance options are provided in the packaging wizard under shortcut section to Pin them to Taskbar OR Start Menu In absence of which administrators will have to deploy a custom script as a different program along with MSIX installation to accomplish the same (Support pin to taskbar or pin to start) ... View more

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

We have many 3rd party apps that creates addin to excel , office , powerpoint, word. So far we have been using script to instantiate object and add addin once the user logs off/login .  We also tried with run virtual key in appv 5.1 but it will always launch excel in its isolated environment which again is not helpful.   Are we planning to handle this behaviour too with MSIX ? ... 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

In order to make in-house developed apps more secure, I think it would be very helpful if the Microsoft Security Risk Detection service would be integrated into the MSIX Packaging tool so you could run the fuzzing engines against your code and detect any vulnerability risks in the code before you seal and sign the MSIX package. This could be licensed and tied to your Azure subscription, I think there's a lot of value in this to help companies get more secure and be able to prove it to their customers, when it comes to LOB apps. @John Vintzel  ... View more

There are times that two applications integrate together, but not using a "plugin" style integration.  Both packages would contain executables and shortcuts, but the second app uses "stuff" from the first package.   The connection groups in Microsoft App-V are good for this situation of packaging separately and deploying as a single (layered) environment.  Because vendors don't usually release in AppV format, we can also package both into a single package if we want.   If the primary app vendor releases in MSIX format, we never want to edit that package directly.  So it would be preferred to package the secondary app up separately and reference the first.  The Modification package doesn't work as it doesn't capture shortcuts (and probably other entry points).  But even if it did I'm not sure launching a shortcut from the add-on package would cause layering to work correctly.   If you need examples of such apps, look no further than apps with EXEs that integrate office components like Word and Excel. ... View more

Modification packages should be able to: add new shortcuts. remove (hide) existing shortcuts in the primary package. replace a shortcut in the primary package. Support for this may also be needed for other manifest file metadata, such as FTAs. ... View more

<Separating out Ideas submissions with multiple items>   List the file type associations of a package in group by the Executable name Have all the FTAs listed under respective executable, provided two ticker options to each FTA – Enable and Enforce Enable option would be to enable the FTA if the checkbox is ticked Enforce option would be to make that the Default program for that specific file type/extension upon install ... View more

https://techcommunity.microsoft.com/t5/msix-packaging-and-tools/msix-package-editor-command-line/m-p/1384287 ... View more

Package captures rely on exclusion lists to prevent unwanted file/registry items  from being captured in the package.  No single exclusion list will ever be right for every capture, so the lists require modification.   The MSIXPackagingTool currently only provides modification through the GUI interface (as far as I know...). It can be seen that the tool saves the tool configuration settings, including any modified list, in a settings.xml file.  The ability to modify the list through other means is needed.  There are two styles of needs: A company team of packagers should generally be able to share a standard settings "template" to be used for most of their packages.  It is far better for all packagers at that company to base their work on the same standard template. Specific apps will require a special template.  This needs to be able to be used to override the standard template when needed.  The use of automation must be considered for this use case also. So here are ideas of changes that could address this: The command line interface will need to accept such a file as an argument.  This applies to both the local command line and the remote (VM) based approach. The ability to set the settings on demand by applying a file in the GUI instead of manual editing of the exclusion list on a line by line basis is needed. The App-V Sequencer had a reasonable model of allowing templated configuration, which could be mimicked. ... View more

I expect that a common use of an IT Pro creating a modification package is to add/alter settings that are in the primary package. Along that line, when I ask to create a modification package and identify the primary package, I would like to have access to assets that are in the package so as to modify them.  The altered components, or those added under package folders/keys, would be overlaid on the main package when running in an environment with the package and add-on package. One possibility is to take an approach like the App-V sequencer powershell "Expand-AppVPackageToLocalSystem", which extracts the file/registry items and lays them down on the system just like when the package was being created.  Incidentally, I am guessing this is how "install" of a MSIX package on Windows 7 would work. Once expanded like this, when in the installation mode of the modification package, all one needs to do is locate and update configuration files/registry items en-situ.  ... View more

In an enterprise scenario, the data and settings associated with an application could be considered to fall into one of three camps: Data/Settings delivered as part of the application from the vendor that nobody should mess with. Data/Settings configured by IT and deployed as part of application and the end user shouldn't mess with it. Data/Settings configured by IT as defaults, and deployed as part of the application but the end user should be able to modify as needed. Ideally software vendors would write their products to support these scenarios, but when we are dealing with packaging older applications this isn't always the case.  And I seriously doubt that we can get everything the way I want it to work, but we need to do better than what we have.   I view the current Microsoft proposed process that IT creates a modification package as generally addressing the only the third scenario. Quite possibly the software doesn't expose a setting so the impact might fit the other scenarios, but that is very application specific.  But when it is exposed, it is unclear if there is a way for IT to easily lock it down.  Possibly with files we can mark the file read-only (I'm not sure if this passes through or not), and in the registry I'm also unsure if permissions pass through.   But even if permissions flow through and will be respected, clearly, to me, the idea of IT configuring via a modification package does not allow for IT enforced changes because it is deployed as an add-on package and the end user can just decide to uninstall the add-on to get rid of IT customizations.   I am concerned that this leads to IT opening the package for edit instead of using the modification package, thus loosing the benefits of update.  So we need a better way for scenario 2 to happen, and we still need to also allow scenario 3 where needed so it isn't simple.   I don't have a solution in mind, but maybe someone can propose something.     ... 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 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

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