Aug 28 2020 04:03 PM
Aug 28 2020 04:03 PM
App is not lunching after installingit from MSIX package, but if I moved it out side windowsapp folder it works well. any idea how to fix it?
Aug 31 2020 08:08 AM
Most likely your app crashes silently. i.e. it fails to read some config file/registry or to write some user data.
You can use the Package Support Framework to trace the crash and try to fix it. Here is an MS Ignite where I made a demo on this topic: https://youtu.be/f3Z7j1XEPgs?t=725
You can use the Advanced Installer Express edition., it's free and gives you the PSF integration shown in the video above.
p.s. I work on the team building Advanced Installer.
Sep 16 2020 01:04 PM
@Bogdan Mitrache I followed the Task manger and I can see the app runs for less than a minute then stops this happen If I started it from the start menu, but If I started it from the windowsapp folder it works well, any Idea?
Sep 17 2020 12:27 AM - edited Sep 17 2020 12:29 AM
As I said above, you need to trace the app and see what is failing upon launch. The Task manager will not provide that info.
Sep 17 2020 10:50 AM
Your situation is not that unusual, it is downright common! In my testing, between 70-80% of traditional windows applications will have issues if just dropped into an MSIX container. Many, but certainly not all, of the issues that occur with running traditional apps in the container can be mitigated. We have the most experience with using the Package Support Framework to mitigate, and that is generally the first approach suggested.
If building the app as a developer, the approach is generally to either use the NuGet package and make configurations needed manually, or to use a third-party install builder that includes the PSF capabilities for you. For example both AdvancedInstaller and InstallShield are known by me to have this built in; perhaps others do as well.
If repackaging, you can use the Microsoft MSIX Packaging tool in conjunction with the free PsfTooling app (as Bogdan indicated). Several third party vendors offer repackaging tools for MSIX as well, and most have PSF capabilities built into their tools.
No matter which approach is used to create the package, Bodgan hit it right on the head in the suggestion to add the PSF and include the TraceFixup (and PsfMonitor) as the first step. This provides monitoring to show exactly what the app requests from the most important Windows API calls, and what was returned. Knowing the cause helps to determine what fixup to apply, and then you can rebuild your final package using the appropriate fixups for that application.
Nov 15 2020 03:17 PM
@TIMOTHY MANGAN The app is working fine if I lunched it from its folder, but it is crashing only if i started it from the start menu. any idea? I already included all .dll files
Nov 16 2020 09:11 AMSolution
@mohamed96ashraf Possibly issue is working directory. The original MSI/EXE based installer creates a shortcut which is interpreted by MSIX to add it to the start menu. When it does this, any setting for the working directory is ignored, and even if it were not set explicitly in the lnk file, the default behavior was to use the folder of the target exe as the working directory of the new process. If you manually launch you'd also get the exe folder to be the working directory. But under MSIX, the working directory is set to the System32 folder.
PsfLauncher may be used to solve this. With PsfLauncher as the target of the shortcut, it doens't care about the working directory and will use a setting in the config.json file to set the working directory of the ultimate target process. PsfTooling may be used when repackaging to add PsfLauncher and solve this.