Enterprises have legacy apps they would like to convert to MSIX.  Allow apps with services to be packaged and deployed as MSIX ... 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

<Separating out Ideas submissions with multiple items>   There could be scenarios such as – an application INI file contains Localhost address which is dynamically written at the time of application deployment Understanding the purpose of MSIX, which is to eliminate the necessity to have custom actions, scenarios such as above turn out to be challenging without installation time actions Having Post-Install script execution supported in MSIX will ease its adaptation for minority of applications as well which required such customization ... View more

MSIX has the ability to add a description via MSIX Packaging Tool and when you create the MSIX App in MEMCM, that information is added to the field automatically. Would like to request to provide the ability to attach an ICON during package creation to inject into MEMCM for the Software Center ICON for the MSIX Application.   Outside of this INCON, the rest is distribute content and deploy the application unless you have supercendence. ... 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

Is there a plugin for Visual Studio code for creating the Appxmanifest.xml with syntax support. Or is something like this planned ? ... 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

We know that services are "on the list" of things to be added to MSIX containers.  When these are added, please consider adding a "spoofing" of the service name.   For packages not distributed via the Microsoft store, it seems reasonable that software vendors will continue to include their own licensing/copyright solutions.  But they rarely "write their own" solution and more often incorporate a component from a Microsoft partner.  The most frequent of these that we see out there is FlexNet from Flexera Software.   This solution, in the MSI world has the software vendor add some library calls to their application plus a Windows Service.  While virtual services work well under App-V, there is one issue that occurs involving this service and it would be awesome to fix this when MSIX adds the equivalent.   The issue is that, under App-V, we can only have one instance of any application that includes this service running on the OS at the same time.  A great solution to this as part of MSIX services would be to "spoof" the service name.  Let each instance have a unique name where needed, but let the application source code still refer to it by the original name and map those calls within the container to the container version.  ... 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

<Separating out Ideas submissions with multiple items>   Include a Launch button in First Launch wizard screen (though the double click action works) ... View more

Adding files in the packaging tool UI is horrible.  You can only add a single file at a time.  The file picker needs to be enhanced to allow multi-selection.  Also consider drag and drop onto the file listing surface. ... View more

This is more of a heads-up that I'm working on this.  The intention is to submit a pull request into the PSF Git to add the functionality in.  Changes are mainly to TraceShim to allow output to ETW, and a new WPF GUI to receive and process them.     Here is a screenshot from the current GUI.  Fuller filtering and search are intended to be added at some point, but basic filtering options are shown. ... View more

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

Sharing the ideas and feature requests put forth during the packaging workshop. First three are the ideas listed in the subject line and following two are more of a feedback than ideas.   First idea relates to shortcut management – advance options.   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   Next idea is relating to certificate management.   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   Last set of idea is to have a File Type Association (FTA) tab.   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   Following are the feedback on features.   Include a Launch button in First Launch wizard screen (though the double click action works) 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   Will look forward for your response and support. ... View more

Sharing the ideas and feature requests put forth during the packaging workshop.   First idea relates to enabling of Process Isolation as an optional feature for enterprise for a limited period and phase out the same once MSIX adaptation grows widely.   Consider a scenario where in the organization would like to upgrade to version 2.0 of an application Sample_app for a new feature it introduced; However, a modification package Sample_mod of version 1.0 is not compatible with latest version of the application It will be very helpful to have Process Isolation enabled for the version 2.0 of Sample_app for a limited period of time until there is an upgraded version 2.0 of the modification package Sample_mod is made available with all fixes This would enable execution of two executables (Processes) with same name (but different version)   Second idea, which is also a request, is to introduce capability to run Post-Install script.   There could be scenarios such as – an application INI file contains Localhost address which is dynamically written at the time of application deployment Understanding the purpose of MSIX, which is to eliminate the necessity to have custom actions, scenarios such as above turn out to be challenging without installation time actions Having Post-Install script execution supported in MSIX will ease its adaptation for minority of applications as well which required such customizations   Last idea is more of a wish list item.   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   Will look forward for your response and support. ... 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

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