Forum Discussion
Multi Application Suite?
- In 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
Given the description of what you want, the Modification may or may not be the best choice...
When you create a modification package, it must include a reference to a primary package, and the modification package may not be installed unless the primary is first present. This makes the modification package good for adding plugins to a main program, but if you need 4 independent programs that sometimes work together, you'd have to make a 5th "primary" program (even if it is just a dummy that has no external start menu).
There is a new feature called "Shared Package Containers" which might be what you need, however this is (currently) only supported on Windows 11 and not 10. This would allow the 4 independent packages plus a different xml file to be deployed that instructs the system to run whichever of the 4 packages are present together. But as I said it only works on Windows 11 so it might be a while before customers are running that.
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.
- You are correct regarding start menu entries not allowed in the modification package, as far as the Microsoft MPT is concerned. However, I never tried forcing one in to see what happens. Certainly, you can put placeholder apps in that primary package that point to a dummy exe that pops up a message to buy the secondary component, and then replace that dummy exe with the real one in the modification package (must use VFS pathing and same path and name).
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.- I 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.- In 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.