11-26-2018 04:26 AM
11-26-2018 04:26 AM
I created an MSIX file which basically contains only files underneath a folder with subfolders. In the normal situation the shortcut contains a working folder. That works fine.
But when installed through the MSIX it fails because the default folder is c:\windows\system32 and cannot find the files it needs resulting in a fatal error. How can I specify the working folder in the MSIX? Is there maybe a possibility in the manifest file?
11-28-2018 02:42 AM - edited 11-28-2018 02:45 AM
This can be fixed with the help of the package support framework (aka PSF). This is a project microsoft launched to help fixup apps without touching their original codebase.
You can integrate the fixes manually, as documented in the github repo (link in the above mentioned article).
This support is available for free for all the fixups included in PSF repo on GitHub, it takes you only a few clicks to include the fixup in your package, without requiring any prior knowledge on how PSF works.
Since you already have an MSIX package, you can simply import that into a new project in the Express edition, to speed up the process, instead of converting your app all over again. You need to start from Import section, UWP AppX project (it also supports MSIX, but the GUI hasn't been refreshed yet)
P.S. Disclaimer: I work on the team building Advanced Installer, you can see more cool MSIX features in my recent Ignite talk.
11-28-2018 04:48 AM
Thanks for your reply. We have an Archtecture license from Advanced Installer. I am using v15.5. I already tried it the way shown in the video but for some reason that doesn't work. When I follow the steps it starts running the application. The application starts in Advanced Installer (Trace apps) but not when I create the MSIX and run it after installing the MSIX, so that is different. I would expect that these two situation should give the same result. And when I am in the application it cannot be closed because it cannot write an ini file. Only way closing it is to kill the process and then Advanced Installer doesn't continue the fixing for some reason.
Now I have followed the instruction in https://docs.microsoft.com/nl-nl/windows/uwp/porting/package-support-framework . Then I get the working directory done but not the redirection unfortunately so closing the app normally doesn't work.
11-28-2018 05:09 AM
Can you send me your advanced installer project over email at bogdan at advancedinstaller dot com?
If you can also send me a download link for the msix package you generated that would be great too, if not, we will try to see what is the problem with your project.
If a fixup is added in our AppCompat view then the app should work correctly when installed separately, just as it did when you use the trace app functionality.
11-28-2018 06:32 AM
I think I understand what is happening with your app, seems like a bug in our tracing support that practically hides the working dir issue.
To trace the app we include our launcher in the package, and it seems that the launcher is incorrectly setting the working dir for your app. Since in your case, we already know you need to fix this, go to Application Details view from your project and set the "Working Directory" field to the folder where your EXE is located, as you can see in the attached image.
This option is in a different page in Advanced Installer because we started fixing this working dir problem long before the package support framework was announced by MSFT.
Now, that you have set the working dir in Application Details view this problem should be gone, so it remains to see how we fix the second issue, with the file write problem. Maybe you can send me the app so we can reproduce it.
When you try to close the app and the file write operation fails, isn't the error visible and highlighted in the log as in our demo video? If it is you could apply the fix and save the project and only afterwards kill the process.
Another solution is to directly add the file redirection fixup using our toolbar options, without tracing the app, as we already know the problem is with specific file. Our default is to redirect .log files, but you can edit that extension to match your specific file type.
01-10-2019 12:37 PM
A third (very ugly option) is to make System32 your "installation folder". Don't shoot the messenger, I said ugly.