Forum Discussion

Tim Mangan's avatar
Jan 28, 2019

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.

 

 

No RepliesBe the first to reply

Resources