Jan 28 2019 05:11 AM
Let's go with a specific example: The Packaging Tool App. And let's say I want to build a modification package for the settings file it stores.
So using the Windows Store for Business I obtain an "offline" copy of the AppXBundle, and then extract the 64-bit .appx file from it (because, 32-bit OSs are so 2010!), and then rename the extension of that file to .msix. This allows me to use in in the Packaging Tool itself.
I now want to create a modification package with the settings file. The settings file itself does not exist in the package, it seems to be dynamically generated when you first run the tool. I know it is written to the [{Local AppData }]\Packages\[{Pkgname_hash}]\LocalState redirection area for the package, but I'm pretty sure that the app didn't try to write it somewhere else and have it redirected here, I believe it called an API that wrote it directly there.
So I do the following:
Using the Windows Insider Preview build (so I have the fixes for modification package layering) I now install stuff.
This makes such a modification package unacceptable to deploy; it will just confuse the heck out of everyone. (Reminder: the MPT is just an example app here).
Is this what is intended, and/or is there a recommended approach to achieve the outcome desired -- that is to deliver an addon that updates these settings?
I am guessing this is "by design" and not likely to change, but would like that stated before we go looking at how to work around this scenario.