Forum Discussion
Tim Mangan
Oct 26, 2018MVP
Shimming apps that start other processes in the package.
I'm not sure if the PSF is designed to handle the need to shim child processes of the shortcut app.
For example, FileZilla.exe will start fzftp.exe as a child process. I can put PsfShimLaunche...
Bogdan Mitrache
Nov 29, 2018Steel Contributor
Hi Vlad, John,
Thanks for the quick reply.
We just used the standard documentation from .NET to launch the process, we didn't write the code specifically to call ShellExecute or CreateProcess. Actually, we left the default value (true) for the property UseShellExecute when we initially wrote the code. If we set it to false, then indeed the child process inherits the fixup.
However, the point here is that the default for this property (UseShellExecute) in .NET changed over the 1809 update and this could affect other user apps too, not just our sample. Apps for which users might not be able to change the code.
This is what we were trying to understand, if this change was intended or accidental?
Regarding your question, we are using our customer launcher because it provides additional functionality (migrating user shortcuts, pins, appdata, etc.. from the old msi version of the app) while also including the PSF support you guys published. It is something we have in Advanced Installer long before PSF was announced.
Also, as I said above, is we set UseShellExecute to false then the fixup is inherited, so there isn't a problem with our launcher, it behaves just as yours.
From our tests, if you have the x86 and x64 executables called PsfRunDll<arch>.exe xchen@lantostechnologies.com, and their corresponding dlls, next to the PSF runtimemanager then the fixups are correctly inherited by the processes, when launching a process for an app with a different bitness.
Vladimir Postel
Microsoft
Nov 30, 2018Thanks Bogdan.
Can you please file it on feedbackhub and I will direct it to the .Net team. It will be great if you can add customers/apps that were impacted.
Changing to shell execute as a default is a reasonable change to guarantee the process launches in the foreground. We should probably add an interception to shell execute as well in our framework.
Vlad