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.
Working (Main Package -> Modification Package):
* Given a main package with VFS\ProgramFilesX86\somefolder\myapp.exe
* Install a modification package that adds VFS\ProgramFilesX86\somefolder\somelib.dll and VFS\ProgramFilesX86\somefolder\someconfig.xml
* MyApp.exe can see both modification package files relative to itself; that is to say, for example, we could call File.ReadAllText("someconfig.xml") and it would succeed. .NET can also load somelib.dll without issue.
Not Working (Main Package -> Optional Package -> Modification Package)
* Given a main package with VFS\ProgramFilesX86\somefolder\myapp.exe
* Install an optional package that adds VFS\ProgramFilesX86\somefolder\myotherapp.exe
* Install a modification package that adds VFS\ProgramFilesX86\somefolder\somelib.dll and VFS\ProgramFilesX86\somefolder\someconfig.xml
* MyApp.exe can see both modification package files relative to itself.
* MyOtherApp.exe cannot see either somelib.dll or someconfig.xml relative to itself. .NET cannot load somelib.dll (FileNotFoundException).
Possible workaround (Main Package -> Optional Package -> Modification Package):
* Given a main package with VFS\ProgramFilesX86\somefolder\myapp.exe
* Install an optional package that adds VFS\ProgramFilesX86\somefolder\myotherapp.exe
* Install a modification package that adds VFS\Common AppData\somelib.dll and VFS\Common AppData\someconfig.xml
* Both MyApp.exe and MyOtherApp.exe can see and load someconfig.xml when we manually use the Environment.SpecialFolder enum to get the path to CommonAppData.
* Working theory is that if we use Assembly.LoadFrom(filepath) in MyOtherApp.exe, passing the CommonAppData\somelib.dll path we generated using the Environment.SpecialFolder enum, then we should (hopefully) be able to load the DLL before .NET tries to do it automatically.
The more I look into this, the more it seems like a bug in the way modificaiton package overlays are being applied when there are optional packages in place, as I cannot for the life of me see why you'd want it to work like this.
JDHIntercede You'll probably need someone from Microsoft to confirm, but I suspect that optional packages are not designed to layer in as you'd like.
However, on Windows 11 (only, unfortunately), it might be possible to add a Shared Package Container (SPC) that lists your mainpackage and optional package. I think the modification package would automatically come in as long as it is deployed, but possibly that would need to be listed as well). The packages listed in the SPC are all considered optional, so what the user gets is independent of the SPC definition. The SPC is (unfortunately) separately installed as an XML file definition listing the packages and a layering order (in case there are any file/reg conflicts). The SPC may be installed either prior to or after any of the packages. See MSIX Shared Package Container - MSIX | Microsoft Docs
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.