Start and manage external process from a WPF app

Question

I have a WPF application and I need to spin up a separate MFC application and then communicate with it. I was going to use Process.Start, but I'm wondering if there is a better way to do this these days. I can research things myself, but I need to know where to start. Thanks.

Edits:

I found this suggesting there isn't. Is this true?

Alternatives to System.Diagnostics.Process.Start()

Thanks.

Are you using the static method or the one that takes a start info? — Gayot Fow, Aug 20 '13 at 15:06
Please clearly explain what you mean by 'communicate with it'. What communication are you expecting to be able to perform? — Sheridan, Aug 20 '13 at 15:07
@GarryVass, either, I'm not sure how they differ except that start info allows one to be more detailed. — Jordan, Aug 20 '13 at 15:12
@Sheridan, I'm talking about inter process communication. I was going to use WM_COPY unless there is a better, cleaner way. What I'm asking here is whether there is another way to run a process that would make communication easier. Because its an MFC project I have trouble even knowing when the application is up. And it's nearly impossible to get its main window's handle because `MainWindowHandle` doesn't work. My plan was to use a memory mapped file to get the handle. It's not ideal. — Jordan, Aug 20 '13 at 15:13
@Jordan, given that, you'll need to think about how to differentiate your question from an opinion poll. But overall, I would use the start info approach if you wanted to capture stdio from the MFC app, otherwise stick to the canonical static method. — Gayot Fow, Aug 20 '13 at 16:01
@GarryVass, I'm not asking for a best alternative. I'm asking if there is a newer variant. I haven't messed with `Process` for years and I've had a miserable time with it then. So I am wondering if things have changed. Its nearly impossible to search for something you don't know the name of. Especially if what you need is vary particular. I thank you, and the rest, for not closing my question like others have done with past questions I've asked. They were NOT shopping list questions either. I am just looking for general ideas, not a best solution. — Jordan, Aug 20 '13 at 16:17
I can attest that there's nothing newer in 4 or 4.5 that would assist you more than what was in 2. Outside of that... I can list some ideas about the Process methods I have used (I have used them a *lot*) and even about the canonical verbs. Some of the driving criteria in deciding which method to use if that's of any use? — Gayot Fow, Aug 20 '13 at 16:59
Yeah, I think any ideas are good. Its up to me to decide what is best for my situation. — Jordan, Aug 20 '13 at 17:05

score 0 · Accepted Answer · answered Aug 20 '13 at 18:45

For your immediate question, there is nothing new in the recent versions of .NET that gives a better or more up-to-date way to start a local executable. Process.Start is (and has been) the way to go.

The simplest, and most convenient, is to select one of the five static methods on Process. Passing strings or a populated StartInfo instance. You would use the latter if you needed more control over how the process got raised. Or of interest in your case, if you wanted to pipe the program's stdio as a stream into your own application. Here's a sample of populating a Start Info instance from one of my utilities...

        ProcessStartInfo start = new ProcessStartInfo(BaseIoConstantsProvider.CommandProcessor)
            {
                Arguments = BaseIoConstantsProvider.KeepAlive,
                UseShellExecute = false,
                CreateNoWindow = BaseIoConstantsProvider.NoDosWindow,
                RedirectStandardOutput = true,
                RedirectStandardInput = true,
                RedirectStandardError = true,
                WindowStyle = ProcessWindowStyle.Hidden,
            };

For the second part of your question, the static method will not do if you need to interact with the process once it is started. From the same utility...

        Process p = new Process { StartInfo = start, EnableRaisingEvents = true };
        p.ErrorDataReceived += PErrorDataReceived;
        p.Exited += PExited;
        p.Start();
        p.StandardInput.AutoFlush = true;
        p.StandardInput.WriteLine(cmdLine);
        p.BeginOutputReadLine();

This example shows a two events being hooked along with reading the stdio from the process. It's great for that purpose, but overkill if you just want to start another executable.

So the main determinate in selecting a start method is the question: does my app need to interact with the process once it's started?

And finally, sometimes you may want to invoke a canonical verb, or even create a verb of your own to start a given process. These appear in the context menu when you right click an item and give you lots of additional flexibility for starting a process. There's an excellent article here http://msdn.microsoft.com/en-us/library/windows/desktop/cc144101(v=vs.85).aspx#canonical on how to implement a verb.

I didn't use this method because the application I'm hosting doesn't support standard IO. But this did give me the inspiration to create a library of objects that made my life so much easier. Thanks. — Jordan, Aug 21 '13 at 13:00
@Jordan, when your library is stable you can put it on Codeplex and give me a shout. Because I have to do this sort of thing all the time and am hence on the look out. — Gayot Fow, Aug 23 '13 at 10:09

Start and manage external process from a WPF app

1 Answers1

Linked