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

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

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

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