AndyB wrote:I have a WPF application.
Application.Current.Shutdown() may be WPF specific, don't know if that exists in WinForms too.
My child process app is also a WPF app, just thought it may be better to have the same type as my main app.
But probably a console app would also work fine?
There is exist only Windows Application or Console application. First doesnt create console, so most time you should prefer this app type, but using Console for debugging can be useful.
WPF apps like WinForms can use Main function as startup object, but this is not enabled by default. So if you already doesnt utilize this, i recommend do it. See WpfOsr sample.
Thing that you really doesnt want is touching excess stuff in child process. This is just doesnt do anything meaningful, but you pay for loading assemblies in best case, and for unwanted inits/objects in worst.
To avoid this, main function can quick test args to determine if it is main browser process and execute another function (or may be even class, not sure how .net 4.5+ speculative background JIT manage profiles and how it deals with /prefetch cmdline arg, which used by chrome) to init WPF/WinForms and perform actions. On other branch of arg test you will end with another function or just CefExecuteProcess call. This would allow for you that child process will not even try JIT unrelated code, as well as load unwanted (wpf) assemblies.
Technically, CefExecuteProcess do same args check, but i'm dislike it interface, because it mix return code with "i'm a main process" - so if child process return -1 for some reason, branch wilk think that it is main process and not error. In my suggestion this will never happens. Also in my programs main process do many things before touching CEF, so it is always good to know which we process running.