Multi Application Suite?

[JDHIntercede]

This probably fits into both the deployment and the packaging channels, but we'll start here. 

I'm trying to work out the best way to approach deployment of a 'suite' of 4 applications. Some customers want a subset in their deployment, others want all of them. I can make a package with multiple entry points, but that's an all or nothing approach that doesn't help those customers that only want a subset. 

I've tried creating individual packages for each app and then using an AppInstaller file to link them all together, which of course doesn't work - I'm guessing because the 'optional packages' need to actually be optional/modification packages that directly depend on the main package, as opposed to just a load of unrelated installs with their own entry points?

I thought maybe I could just create a base package that doesn't do much apart from creating the VFS layout, then having each of the apps as optional modification packages on that base package, but it doesn't look like this is supported either (tooling doesn't seem to like optional packages with entry points). 

To add to all of this complication, these apps can also have plugins installed over the top - this means that whatever the output of all this is, it needs to be able to support modification packages being overlaid. I'd also rather not have to have different flavours of the modification packages that the customer has to pick depending on the base package (i.e. I'd like to use the same package regardless of whether 1 app was installed standalone or all were bundled together).  

Does any of this make sense, and, if so, is there a way to do what I'm trying to do or am I going to have to accept that to install the 4 apps our customers will need to run 4 installers, or that I have to bundle them all up into one package and customers get all 4 whether they like it or not?

TL;DR: Would like to be able to have the flexibility to deploy 4 apps individually where required, or, optionally, as an arbitrary collection of >1 of those apps in one hit. 

[#2]

Okay, I think I've worked out where I was going wrong; because the documentation is a bit all over the place I was conflating optional *modification* packages with *optional packages*. I think I've got my head around it now, but the documentation and vague naming conventions are not hugely helpful - I ended up using the Wayback Machine to look up the delisted Microsoft blogs, which helped steer me in the right direction.

For any Microsoft people reading this: the documentation for creating MSIX packages outside of the most basic use-cases is quite poor and could really do with an overhaul. There's huge omissions (only explaining how to create related sets with Visual Studio, for example), links to non-existent blogs, and just lots of seemingly related stuff spread around in disparate places. Trying to get something working has not been a fun experience at all.

[#3]

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.

[#4]

@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.

[#5]

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.

[#6]

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.

[#7]

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.

[#8]

I'm actually glad you aren't pushing not-quite-necessary shortcuts down on end-users;)

[#9]

What stops you from building an MSI wrapper over all the MSIX packages (to deliver them as single installer for all the apps) and keeping the MSIX packages as a separate for folks that need just some of them?

In this case, the MSI would simply act as a script, without affecting the payload of the packages or leaving any garbage on the system.

[#10 · Accepted solution]

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-...