PSF tool DynamicLibraryFixup32.dll fix issue @ config.jason file

[Siva116]

Hi All,

 I created an MSIX package with the help of Timothy Mangan PSF Tool available in MS Store. Injected all required fixes like DLL Fixup and File Redirection Fixup for a 32 Bit application.

As the application is 32 bit.. the PSF Tool copied all required PSF file DynamicLibraryFixup32.dll, FileRedirectionFixup32.dll, PSFLauncher32.exe, PSFRuntime32.dll etc.. to somewhere in VFS folder. but my question is when I cross check the config.json file content.. instead of seeing information of 32 bit DLLs like FileRedirectionFixup32.dll, DynamicLibraryFixup32.dll, I saw FileRedirectionFixup.dll, DynamicLibraryFixup.dll.

1. Please suggest whether this will work or not? because the copied files were xxxxx32.DLLs, but in json file we have xxxxxxx.DLLs?

2. Even though I applied the fixes the DLL issues with DynamicLibraryFixup32.dll, the application is not working as expected. My application is looking for NSTRC.dll at "VFS\ProgramFilesX86\IBM\Personal Communications" instead of "VFS\ProgramFilesX86\IBM\Trace Facility" and this location was already available in json file.

3. Later as a part of troubleshoot, I placed one more copy of the required NSTRC.dll at "VFS\ProgramFilesX86\IBM\Personal Communications" and the application shortcut started working, Is this the only work around to resolve the issue, or do have any other work around to do in json file?

Please suggest @TIMOTHY MANGAN

Thanks in Advance.

[#2]

Hi Siva,
Can you please share some more details around this. Which app were you trying to convert?

Thanks

[#3]

@Siva116 

There are applications that open dlls in strange ways and I've found a couple for which the DynamicLibraryFixup doesn't solve dll not found.  Generally these seem to be apps written originally written for linux/unix and ported to Windows -- but natively written Windows apps could possibly do it too. Fortunately, you have other options.

• With more recent OSs, if the app is simple you can sometimes add the SearchOrderLoader element to the AppXManifest with the folders containing dlls.  This doesn't work, however, if the same name dll is present as both 32 and 64 bit forms in different folders. 
• The work-around that you did.  This might become a complex approach in some apps as you have to work serially (once you fix one you find there is another, and then another, etc...) in complex apps, so often not the best choice.
• Move all dlls in the package to the VFS\SystemX86 or VFS\SystemX64 folder.  If everything is the same architecture this is easy to do, but if the package is a mix of bitnesses, care must be taken.   This should probably always work.