Forum Discussion
Multi Application Suite?
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.
- 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
- 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.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.
- 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
