INI settings in App Directory issue

[John Wildes]

Hi all

I am trying to MSIX package an application that uses an INI file stored in the Application Directory itself to coordinate connections to an SQL server.  Is there a way that I can tell my MSIX package to store this INI file in the user APPDATA/Profile folder and reference it there vice looking at C:\Program Files (X86)\<Application>\control.ini file? 

By design you cannot edit anything in the application directory when deploying the MSIX app.  

thanks

john

[#2]

@John Wildes  Can you please clarify what you want a bit more?  Possible examples include:

• I just want the app to use the file but allow the file content to be changed by the app.
• I want the file in that particular location because I use a third party tool to manage it from that location and roam it for the user.
• I want the ini file kept completely out of the package and will be managed externally or using package scripts. I just want the app to look for it there.

[#3]

@TIMOTHY MANGAN 

Thank you for the suggestions!  I realize I might not have been clear in my description of what I wanted.  This is what I'm looking for :

• I want the ini file kept completely out of the package and will be managed externally or using package scripts. I just want the app to look for it there.

Thoughts on how to accomplish this?  

[#4 · Accepted solution]

@John Wildes 

So if I assume that changing the code of the app isn't an option and that you are repackaging, I would look at one of two methods:

1.  Use the Application Compatibility Toolkit from the Microsoft ADK to create a custom file redirection fixup.  This is done prior to the packaging.  You identify the exe and create a compatibility shim with a file redirection rule for that one file pointing to the external location. The output of this will be a ".sdb" file.  Then just package the app as normal. You will have to cause the sdb file to be coped to target systems and installed using the "sdbinst.exe" OS utility. Since this must be performed before the user starts the application, MSIX package scripting is not an option to do the sdbinst (which needs elevation anyway). So you'd be using an external method to copy the sbd and ini files and running the command.
2. Repackage the app using the Package Support Framework and include the FileRedirectionFixup.  This will cause an automatic read redirection to the %AppDataLocal%/Packages folder for the package.  If packaging using the Microsoft MSIX Packaging Tool you can use PsfTooling to add and configure the PSF into the package.  Just ask for the FileRedirectionFixup and keep the default settings.  You can then use your external method to deploy the file to the place the app under the redirected location.  The exact path under the "Packages" folder will depend on how you package. Since you are now using the PSF, you can also add start of application script to perform the ini file copy for you.  The PsfScripting has a pseudo-variable %MSIXWritablePackageRoot% which can be helpful.

Neither method is simple to provide detailed instructions, but the above outlines the basic techniques.

[#5]

@TIMOTHY MANGAN 

Thank you for the insight! I don't spend any time doing this at all, but I understand what you're explaining.  I'll dig into these two options.  Would you happen to have any links to Microsoft documentation surrounding the concepts that you're explaining below?  I've got some promising results from my search queries, but if you have some favorites that you can share that would be awesome.

Thanks again!

[#6]

@John Wildes Documentation is pretty light. 

For AppCompat Toolkit you look for videos by Chris Jackson.  He has old, but great videos showing how to do it.  

For the Psf, there is minimal docs on this topic (if any) via aka.ms/MSIX . The GitHub repro has scripting examples in the readme here: https://github.com/microsoft/MSIX-PackageSupportFramework/tree/master/PsfLauncher

I have some PsfTooling documentation and videos on my site at tmurgent.com (although nothing on scripting at this point).  We do cover this sort of thing in our paid-for trainings.