Forum Discussion
Philip_Eve
Oct 19, 2021Copper Contributor
Combining optional packages and modification packages
Hi. I've a question that relates to both optional packages and modification packages.
I have created a "related set" consisting of an .msixbundle (the main package) and an .msix (the optional package). These packages are for sideloading, not for the Microsoft Store. Each package contains standalone executable applications.
I have also created a modification package that adds additional files (specifically, configuration files) to the virtualised filesystem of the main package.
The issue I have is that I want the applications that are part of the optional package to run in the same virtualized context as the main package. Meaning that:
- they would see the same virtualized filesystem;
- they would see the same virtualized registry;
- the modifications made by the modification package would take effect also for the applications in the optional package (so installing the modification package would provide configuration both to the apps in the main package and to the apps in the optional package).
However, the observed behaviour is that the apps in the optional package have a separate virtualized filesystem from those in the main app. Is there a way to change this so that they see the same virtualized resources?
I've also asked a couple of questions about this on Stack Overflow:
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.
- Philip_EveCopper Contributor
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.
- Philip_EveCopper ContributorThe previous remark about storing configuration in the registry, or indeed in some filesystem location other than in the Program Files folder (alongside the executables) is premature. The design of the relevant facilities in .NET Framework really, really doesn't want you to put (for example) a Connection Strings file anywhere other than at a path relative to the executable. So I need the connection strings file to be in the virtualized file system, but that means that the apps in the optional package are unable to read it because they don't share the same virtualized file system! It is as though whoever at Microsoft designed MSIX did so with deliberate contempt for the people who designed the configuration file system!
- JDHIntercedeBrass ContributorDid 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