Forum Discussion
Incorrect VFS references in AppXManifest due to MSIX Packaging Tool 2022.110
There appears to be an issue in how the packaging tool translates paths into relative VFS paths in the AppXManifest.
Although I suspect the issue is likely more general than this specific case,...
kalyaniverma
Microsoft
MicrosoftWe would like to get more information on the app that you are trying to convert. Is it possible to share the name of the app or submit an issue through the feedback hub?
The application includes a shortcut to run powershell.exe against a PS1 file that is inside the package. To repackage this, because the normal target exe is not in the package, it requires adding the PSF and replace the shortcut with one pointing to a copy of PsfLauncher. PsfTooling traditionally would place the launcher (and PsfRuntime.dll) in the folder of the original target exe, which is under a subfolder of the Windows\System32 folder. So these are files that are then captured as VFS\System. There are likely numerous other examples out there, but this is a simple one to reproduce.
NOTE: I have since put special handling of this example in PsfTooling 5.0, but it only solves the issue (for this app) by avoiding this folder for files it adds. Other applications using this folder that require manifest reference, such as a shell extension component dropped in the System32 folder, will also have this problem.
This mapping is clearly wrong, but I also recognize the pain it might cause to change it at this point.
NOTE: I have since put special handling of this example in PsfTooling 5.0, but it only solves the issue (for this app) by avoiding this folder for files it adds. Other applications using this folder that require manifest reference, such as a shell extension component dropped in the System32 folder, will also have this problem.
This mapping is clearly wrong, but I also recognize the pain it might cause to change it at this point.
- kalyaniverma
Thank you for your feedback. If you are able to share the app or log an issue through feedback hub, we will be able to do more research on this.
- Just create a package with a ps1 file that sleeps and an new lnk file (shortcut) to target powershell.exe and argument -file path to ps1 file. It is the path to powershell that is incorrectly variablized.