I'm developing an aplication, that is opening a file with associated app for file extension(this part is provided by shellexecute), and wating for it to exit, and then continue to work on file. I know Process.Start(...) may return null e.g if there is an process of same up running, etc. I solved it by asking user to close all windows of default app before proceeding. I'm getting associated .exe path from FindExecutable(...) imported from shell32.dll and then calling in loop this and also checking if list lenght is 0.
var processList = new List<Process>(Process.GetProcessesByName(Path.GetFileNameWithoutExtension(defaultExecutablePath)));
And here I've met a wall I can't overcome. If default app is any kind of app from Microsoft(Edge, Photos, Movies) FindExecutable(...) returns empty string. However Process.Start(...) somehow starts the right default app which for example is Microsoft Edge(for .pdf) but it returns null even if no instance of Microsoft Edge is running, so I can't wait for newly created process to exit. It all works nice with an exception in case if app is the one provided by Microsoft.
var newProcess = Process.Start(openPath);
if(newProcess == null)
{
throw new ProcessStartNullException();
}else
{
newProcess.WaitForExit();
}
Can I somehow exploit it or re-design awaiting for exit?
It's not because they are Microsoft apps, It because they are UWPs, and UWP is running in a container process called ApplicationFrameHost, so you need to figure out the real process under that ApplicationFrameHost then monitor it. Also, many Win 10 UWP app's processes won't terminate immediately after users close their window so they can have a warm startup instead of cold startup for a better performance. It will first suspend the application and then later, if needed, terminate it. So even you can find the real process, you can't always relay on it to determine if the UWP window is closed or not.