Forum Discussion
Question on Modification Package to "store app"
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:
- Start the tool (which generates the initial version of the file on disk).
- Thinking ahead, I change the default exclusion list to not exclude [{Local AppData }]\Packages.
- Start the modification package wizard (using 1.2019.110 so the manifest is right), choose the .msix file & add my cert.
- But now where to place the file? The instructions say I should have the Win32 version of the software installed. This doesn't exist to me but I have the package installed and maybe that's good enough? (In which case the language on the modification UI should be updated).
- I just overwrite that file with the replacement.
- Clean up in the editor so that I only have the one file and save off the package.
Using the Windows Insider Preview build (so I have the fixes for modification package layering) I now install stuff.
- If I install the main tool package plus the modification package, and then run the tool, I get the changed settings.
- If I add the settings after running the tool, the changes have no effect, because the local copy in the native AppData\Local\Packages wins.
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.