Forum Discussion
Combining optional packages and modification packages
In case anyone is interested, and just so I don't leave another dangling thread, this is the redesign we've ended up going with:
* All apps are included in the main package, but only the config tool has an entry point (ergo only one with a Start entry).
* Optional packages add simple exes that launch the existing applications from the main container. The exes are registered as entry points, effectively allowing us to add Start entries for the apps that are already installed in the main package.
* Since all the apps are actually in the main package, even though they are only enabled when the optional package is installed, they can all see any DLLs and whatnot that have been overlaid by modification packages relative to their assemblies - this means we can ship our separately licensed components without any problems.
This works for us since there isn't any licensing issues with the apps themselves, just the components we want to ship in modification packages, and we really just wanted the admin to be able to choose what they add to the Start menu. The apps themselves aren't very big either, so including them all in the main package isn't a problem.
Hopefully this is useful to anyone trying to do something similar. I'll also link here from the other thread for anyone getting here from a web search.
The plot thickens...
I just did some experimentation with running Regedit.exe via Invoke-CommandInDesktopPackage. I was expecting that the two apps would appear to have separate virtualized registries, as with the VFS. But in fact it seems as though they are sharing a virtualized registry. We may be able to switch to using the registry for config instead of configuration files.
- Did you get anywhere with this? We've just hit the same problem (Optional Package cannot see overlay from Modification Package), and were working on the assumption it would work based on the line "Optional packages and related sets all run inside the main app's MSIX container" in the documentation here: https://docs.microsoft.com/en-us/windows/msix/package/optional-packages
I regret that I never got any further than my previous messages here indicate. The reason why I never pushed any further on this is that we revisited our design decisions, and changed them in such a way that the architecture I had planned (main package + optional package + modification package modifying both) was no longer the favoured approach. It does sound as though the problem you are currently facing is the same problem we encountered.
- Just to expand on this, I've used Invoke-CommandInDesktopPackage to run PowerShell inside the container and have verified that the files added by the Modification Package are showing up in the VFS, but they are not detected by the application being launched from the Optional Package.
If I make the app in the Optional Package into a Main Package, then change the Modification Package to apply to that, the file is detected correctly.
Based on this, it looks like:
* When the application is the Main Package it can load files (in this case, DLLs) that have been applied by a Modification Package.
* When the application is an Optional Package on top of a Main Package, it cannot load files that have been applied by a Modification Package.
Is this intentional? It doesn't seem to gel with what I'd expect, particularly now I've confirmed the files are in the expected place in the VFS.- JDHIntercede I'll admit to being a bit confused by creating a related set and optional package.
If I want to have a primary package with a modification package that contains either different files or registry settings and this modification package contains no entry-points (Shortcuts/FTAs, etc..) Then all I need is the primary package and a package created as a modification package.
I believe that it is necessary that files in the primary and modification package exist as VFS files in their respective packages for the layering to work. (This is a restriction that Microsoft should, and may have fixed, but as I've never seen that they did I always make the packages this way).
The modification package references the main package by using the full package family name, and may not be installed until after the primary package is installed.
As such, all changes made by the app when running with the modification package are redirected based on the primary package family name.
