Forum Discussion
Multi Application Suite?
- May 26, 2022In case anyone is interested, this is the approach I ended up going with: https://techcommunity.microsoft.com/t5/msix/combining-optional-packages-and-modification-packages/m-p/3432402/highlight/true#M3044
TIMOTHY_MANGAN Thanks Timothy - sounds like the eventual solution I've come to is the right one; I'm making a base package that just provides a config tool, then optional packages for each of the actual apps that, when installed, consume the config created by the tool. This works well in that it allows us to use an appinstaller file to bundle them together into 'single' installs, share config between everything, and simplifies shared plugins since everything is in the one container.
I've read about shared containers, but, as you suggest, a hard requirement on Windows 11 isn't an option for us at this stage.
The only question I guess I have is between Modification Packages and Optional Packages - am I right in thinking that only the latter can include an entry point and add a start menu entry, forcing me down the related set approach? I've read contradictory stuff in the docs about what can be done with each package type (e.g. the idea that you need an optional package related set to load code, but I've been able to load a DLL from a simple VFS modification package during investigation), which has confused the issue somewhat.
I do have a couple of free eBooks that I wrote on MSIX (one for IT Pros, one for Developers) in conjunction with Devs from some of the leading third-party vendors that you might want to read here: https://www.tmurgent.com/appV/en/resources/books.
- JDHIntercedeDec 08, 2021Brass ContributorI like the idea but I think we'd get pushback on having the entry points for apps that aren't really installed on customer systems. It's not so much a case of the different apps having different licenses, but more that we want our customers to have the flexibility to deploy different sets to different users while also being able to bundle everything up into a one-hit install. With the optional package approach they can configure different appinstaller files for different users/groups, and deploy the subset of apps (and any of their own modification packages for 'hardcoded' config) in one hit.
Cheers for the link - I've already perused the Advanced Installer one but I hadn't seen the new 2021 developer book so will take a look at that. Hopefully it plugs some gaps in the official docs.- JDHIntercedeDec 08, 2021Brass ContributorIn the MSI world we'd have one installer with checkboxes to allow the admin to pick the things they want to install (which could be driven by params in a silent install) - I'm effectively trying to create something that gives them a similar deployment experience, but obviously taking into account the fact that the installer itself can't be customised, hence the idea to use appinstaller files to achieve the one-hit install by deploying the main package with the customers choice of optional packages (we'd basically give them a small guide on how to configure this themselves).
It feels like this is the best approach from my understanding so far, but perhaps the book will illuminate a different path.- Dec 08, 2021I'm actually glad you aren't pushing not-quite-necessary shortcuts down on end-users;)