Proposal for a MSIX Packaging Tool “Plug-In” Strategy

Proposal for a MSIX Packaging Tool “Plug-In” Strategy
0

Upvotes

Upvote

 Oct 12 2018
2 Comments (2 New)
Not at this time.

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.
    1. 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.
    2. 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!

 

Comments
Microsoft
Status changed to: Duplicate
 
Microsoft
Status changed to: Not at this time.