I want to highlight an issue with implementing PSF shimming that I ran into. It was particularly annoying because the symptoms did not match the real problem.
The issue is the need for alignment of the shim launcher, the shims, and the target application when it comes to what I call "bitness". "Bitness", is how I describe if the app, or a component, is 32-bit or 64-bit. This shows up in some tooling as "Architecture", but as an overused term that one can be confusing to people.
Here is what I (think I) know:
Starting out with the easy part, if the target application is a 32-bit exe then you need to use the 32-bit launcher and 32-bit shims. If the target application is 64-bit, then you need to use the 64-bit launcher and shims. The impact of this is, unless we build a radically different launcher than in the PSF repository currently, it will become necessary to have independent 32 and 64 bit MSIX packages if the vendor has 32 and 64 bit exes for the application.
But then it gets messy with "AnyCPU" executables. AnyCPU is a build option that produces a single exe or dll that will run 32-bit on a 32-bit OS and 64-bit on x64 (I believe that on x64 an AnyCPU dll will run in the bitness of the process that loaded it).
On an x64 OS when a 32-bit launcher creates the application process using an AnyCPU exe the application process becomes 64-bit (configurable in the linking, but by default 64) and will need 64-bit shims. So even though the vendor supplies only one exe, we still need two different packages with different bitness shims (and probably launcher for simplicity).
But it is NOT obvious that an executable is AnyCPU. And as I learned over the past two days not so easy to diagnose as CreateProcess returns with a file not found error.
If PSF is going to be "easy", we need to make bitness issues handled automatically. As the current shims are C++ based I don't think we can make them AnyCPU.
If you are building an installer, you can include all components. But if you are an IT pro repackaging with "the tool", the installer only puts down the bitness specific bits associated with the OS you capture on.
Given that we are capturing and deploying to Windows 10 - this isn't much of an issue because nobody uses the 32-bit version of the OS (well, except in VMs where memory matters I suppose).
It sounds like the PSF components actually handle more of this automatically than I thought - making sure they insert the right bitness shims if we supply them. But until I can test real-world scenarios on this I'll hold on making a final judgement.