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 dll
s and single exe
file (which is probably calling these dll
s 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.
There are several considerations:
Depending of the answers.
Create bindings if:
Use executables:
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.
如果dll写得很好且没有内存泄漏,那么最好使用dll,因为它不需要新的进程创建开销。
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.
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 depends on the way external application uses it's dlls.:
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.