Dec 06 2021 08:31 AM
Dec 06 2021 08:31 AM
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.
Dec 06 2021 11:52 AM
Dec 07 2021 12:12 PM - edited Dec 07 2021 12:13 PM
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.
Dec 08 2021 02:42 AM
@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.
Dec 08 2021 03:43 AM
Dec 08 2021 04:01 AM
Dec 08 2021 04:08 AM
Dec 14 2021 02:33 AM