Unlike traditional applications, the working directory for any unfixed MSIX package will be the System32 folder. This can break applications because:
- The application uses the working directory to find other files.
- The working directory is also used in the list of directories to load dlls from, so it might not find a needed dll.
There are a few of reasons why the packaged application can't find it's dlls in the package from the package created by the Microsoft MSIX Packaging Tool (MMPT):
- Incorrect Working Directory
- "App Paths" not supported by MMPT
- Path variables not supported by MMPT
- App uses non-standard APIs to load dll
TMEditX can fix up all of these issues, and the following will help you understand when and how.
- Incorrect Working Directory.
This is automatically detected and fixed by using PsfLauncher.
- "App Paths" not supported by MMPT.
This is automatically detected. If the PSF is used, it will be fixed by the DynamicLibraryFixup. Otherwise, it is fixed by using LoaderSearchOrder in the AppXManifest.
- Path variables not supported by MMPT.
This is automatically detected and Path variable folders that have VFS references in the package are added to the LoaderSearchOrder in he AppXManifest.
- App uses non-standard APIs to load dll.
Even with all of the above, we have found at least one application that uses a non-standard API to load the dlls and none of these can help. To date, TMEditX cannot detect this case, and it must be caught by testing the package. The app was built for Linux and ported to Windows. For these, TMEditX includes two "Available" fixups, meaning they are not automatic but on demand.
If all the dlls are the same bitness (32 or x64), then a fixup will appear that will copy all the dlls in the package to the root of the package. This location is always searched, even with this strange API.
If there are both 32-bit and x64 dlls in the package, then the fixup will appear that will copy all the dlls in the package to the appropriate VFS\SystemX86 or VFS\SystemX64 folder. These are also always searched, even with this strange API.
To date, this covers all known cases of "dll not found" with MSIX packages. Share info with us if you find something new.
The Microsoft MSIX Packaging Tool (MMPT) will intentionally ignore certain application shortcuts, or give you more than you wanted. The evidence of what the installer did is still normally inside the package, just not exposed to the end-user and TMEditX can in most cases add these back into the package.
The Microsoft MSIX Packaging Tool (MMPT) will select one of the applications in the package and make it the default application. We have no clue how the tool picks which one is first as it does not seem to depend on order laid down by the installer or the alphabet. This will be the first application listed in the AppXManifest, and it has the following effects:
- The shortcut icon for that app will be used as the package logo. This is normally seen only by someone manually installing the package by clicking on the MSIX package to install it. It is possible that some management utilities will also use the package logo.
- If the package is manually installed from the MSIX file, the AppInstaller has a checkbox (enabled by default) to launch the default app upon completion of the installation.
This means that the end-user will probably never know, nor care. But in case you do, here is what you can do about it.
- In the MMPT, after completing the installation and on the page showing the shortcuts (at least the ones the MMPT supports), you can actually use the scrollbar on that display to see the far right-side of the list, where there is an additional hidden field called "default". Just click the radio button of the shortcut you want to be the default and it will adjust the package before you save it.
- In TMEditX, use the "Applications" tab at the top to view all of the applications. There you can select which one to be the default also.
As mentioned in the FAQ TMEditX and Shortcuts Missed by the MMPT, the Microsoft MSIX Packaging Tool (MMPT) will mess up what the application intended with start menu folders, and TMEditX will generally fix that for you via a couple of fixups generated by the analysis.
But there are installers that were built for Windows 7 (or before) that maybe didn't use folders but now that the start menu is shows alphabetically you'd like them to be grouped under a folder.