Which approach better: Process.Start or call DLL directly?

Question

In our team we've faced with the choice: we need to call external third party code and process its output from our C# code.

The third party code available in two forms: set of dlls and single exe file (which is probably calling these dlls on its own). And possible approaches could be: use Process.Start statement to run executable and catch its output. And another one is to call dll directly.

I'm trying to understand which approach should we use.

On one hand calling executable is simple, but on the other — it does not feel robust.

On one hand calling dll looks more right way to do the job, but on the other — it might be really complex task to provide C# binding for all functions we have in native C code.

But I need more substantial analysis on this topic to make a final decision. Does anybody faced with the same question before, maybe you could share your finding.

It would be very useful!

EDIT: I'm talking about video conversion in this particular case. I need to get video stream from user and convert it into one video format for all. It is possible to call ffmpeg to do the job, and everything is OK until something goes wrong and I need either restart encoding or take any action. I could not estimate how long it will take and if I will need to convert several videos in parallel ffmpeg will not be that flexible, as I plan it to be...

At least as I see it now. Maybe more issues will come up as I dig in.

Answer 1

There are several considerations:

1. Do you have the source for dlls?
2. How much do you intend to call those dlls?
3. How complex are the APIs of dlls, and your usage?

Depending of the answers.

Create bindings if:

• You will call dlls frequently. Direct call is much faster.
• You have the source and check how good they are. Otherwise you may have huge problems with memory leaks, calling conventions etc.
• APIs of dlls are not too complex, so you won't need to send C++ objects to them, etc. Or implmenet a lot work already done in exe.

Use executables:

• If you need to run them only occasionally. Overhead of creating another process does not matter to you.
• If you not sure about quality of the code. It will be much safer and robust for your code, not to load some badly implemented dll. You can always try to run .exe several times if a problem occurs. But it a dll crashes your app, you can't do anything.
• If the API is very complex, and exe have a lot of functionality, that you will have to reimplement.

Answer 2

I'd say this would depend on how much granularity would your code expect in terms of api support from the library.

If executable encapsulates the workflows well enough for you, you could benefit from simplicity of invoking the executable.

Also, since you mention this is native C code, adding DLL reference would mean having to deal with unmanaged code, which I'd personally not go for unless there is no option for me.

Answer 3

If the dll is well written and with no memory leaks it's better using the dll, since it doesn't require new process creation overhead.

Answer 4

I'd say it all depends on your requirements, time frame, how stable the output of your exe file is, and how easily it can be parsed. Both ways are doable.

For example, Mercurial considers its console output the primary way of interacting with it - even though one could use its Python code directly.

On the other hand, calling C functions from C# is fairly easy so this may be an option as well. If you, however, need to map hundreds of C function, you must ask yourself whether you have the time to do so.

Answer 5

EXE There is single main entry to be called, so you cant call the functions directly. When you call an exe, a new process will be created entry thread is called in context of main thread of that process.

DLL Gives you more flexibility by calling functions directly there is an entry point per function system loads a DLL into the context of an existing thread

so calling DLL is much better for computational resources, and provide more flixibility. talking into consideration that you can call a DLL from managed and unmanaged code, and you can call managed and unmanaged dll from C#

If DLL has a come interface you can add a refrence directly, and if doesnt have you can still able to call it like below

 [DllImport(@"TestLib.dll")]
    public static extern void InitParam([MarshalAs(UnmanagedType.LPWStr)] string inputFile,
        [MarshalAs(UnmanagedType.LPWStr)] string outputFile,
        [MarshalAs(UnmanagedType.LPWStr)] string templateFile,
        [MarshalAs(UnmanagedType.LPWStr)] string userName,
        [MarshalAs(UnmanagedType.LPWStr)] string manifestFilePath,
        [MarshalAs(UnmanagedType.LPWStr)] string usersRightList);

in simple words you import the DLL and map the parameters to .net types using marshalling

Answer 6

Answer depends on the way external application uses it's dlls.:

• Call exe, if it calls multiple dll functions, multiple times and its business process is big and complicated - you don't want to reimplement all exe logic in your C# code.
• Call dll directly, if exe only calls one-two functions from dll, call order and parameters are well known or absent at all.

I general, I would prefer calling dll directly, because this removed a lot of overhead and possible problems with spawning new process and processing its output. And don't be afraid of native code, if your dll functions are simple then with PInvoke you will be able to easily call those functions.