For security purposes, we would prefer to keep all of the VCRuntime dlls out of MSIX packages and instead replace them with Microsoft.VCLibs.xxx package dependencies.

For most applications (being repackaged), we can simply remove the files from the package and add the dependency in the AppXManifest file.  LoadLibrary happily finds the files in the dependency package without need of the PSF.

There are applications, however, that have folders containing numerous managed dlls along with the VCRuntimes in a folder, and use an internal manifest in the exe that includes a 

               Dependency / dependentassembly / Assemblyidentity that lists the folder,

and then an external manifest in that folder that lists all of the dependent dlls to be loaded.

When the application process is launched, the internal manifest is processed and we see the dlls listed in the external manifest being located using the API  RtlDosApplyFileIsolationRedirection rather than load library.

It appears that this API does not look at the location containing AppXManifest PackageDependencies thus the dlls are not found and the launch of the exe fails.  The PackageDependencies should always be respected or they are useless.

I have an example package (Blender) that has this condition if you’d like to look at it.

​For security purposes, we would prefer to keep all of the VCRuntime dlls out of MSIX packages and instead replace them with Microsoft.VCLibs.xxx package dependencies.
 
For most applications (being repackaged), we can simply remove the files from the package and add the dependency in the AppXManifest file.  LoadLibrary happily finds the files in the dependency package without need of the PSF.
 
There are applications, however, that have folders containing numerous managed dlls along with the VCRuntimes in a folder, and use an internal manifest in the exe that includes a 
               Dependency / dependentassembly / Assemblyidentity that lists the folder,
and then an external manifest in that folder that lists all of the dependent dlls to be loaded.
 
When the application process is launched, the internal manifest is processed and we see the dlls listed in the external manifest being located using the API  RtlDosApplyFileIsolationRedirection rather than load library.
 
It appears that this API does not look at the location containing AppXManifest PackageDependencies thus the dlls are not found and the launch of the exe fails.  The PackageDependencies should always be respected or they are useless.
 
I have an example package (Blender) that has this condition if you’d like to look at it.  Read More

​