Currently, we create an MSI for each workload pack. However, workloads can be made up of many workload packs. Maui for example has something like 40 workload packs, many of them because they depend on various Microsoft.Extensions NuGet packages which they would like to include as library packs. Installing all of the workload packs as MSIs can have a high overhead.
We should support grouping multiple workload packs into a single MSI. The MSI workload manifest could include an extra file that could map from workload packs to an MSI that includes them. The MSI-based installer would then use that mapping to find the MSI to install.
The set of workload packs that should be grouped together in an MSI would be defined manually in the repo that created the workload manifest MSI. The MSI creation tools would create the mapping file and the grouped MSIs based on that.
It's possible that the same workload pack would be installed by multiple different MSIs (for example if two different workloads in different repos depended on the same pack). We should generally try to avoid this because it will increase the overall installer size, but the installation system should allow this. If there were multiple MSIs that installed a given workload pack, the installer could install both of them if needed and they shouldn't conflict with each other (because the workload packs are all side-by-side).
For reference, this is the same as library packs that we've discussed before.
Currently, we create an MSI for each workload pack. However, workloads can be made up of many workload packs. Maui for example has something like 40 workload packs, many of them because they depend on various Microsoft.Extensions NuGet packages which they would like to include as library packs. Installing all of the workload packs as MSIs can have a high overhead.
We should support grouping multiple workload packs into a single MSI. The MSI workload manifest could include an extra file that could map from workload packs to an MSI that includes them. The MSI-based installer would then use that mapping to find the MSI to install.
The set of workload packs that should be grouped together in an MSI would be defined manually in the repo that created the workload manifest MSI. The MSI creation tools would create the mapping file and the grouped MSIs based on that.
It's possible that the same workload pack would be installed by multiple different MSIs (for example if two different workloads in different repos depended on the same pack). We should generally try to avoid this because it will increase the overall installer size, but the installation system should allow this. If there were multiple MSIs that installed a given workload pack, the installer could install both of them if needed and they shouldn't conflict with each other (because the workload packs are all side-by-side).
For reference, this is the same as library packs that we've discussed before.