Question on Modification Package to "store app"

MVP

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.

 

 

0 Replies