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.