Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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.

like image 630
shytikov Avatar asked Jan 24 '13 11:01

shytikov


People also ask

Can a DLL call another DLL?

You can use load-time dynamic linking or run-time dynamic linking in your DLL in the same way as in the executable. The only restriction is not to call LoadLibrary from your DllMain function to avoid deadlocks.

What is process Start?

Start(ProcessStartInfo) Starts the process resource that is specified by the parameter containing process start information (for example, the file name of the process to start) and associates the resource with a new Process component.


1 Answers

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.
like image 149
Vladimir Perevalov Avatar answered Sep 27 '22 18:09

Vladimir Perevalov