Quale approccio migliore: Process.Start o chiama direttamente la DLL?

Question

Nel nostro team ci siamo confrontati con la scelta: dobbiamo chiamare il codice esterno di terze parti e processarne l'output dal nostro codice C#.

Il codice di terze parti disponibile in due formati: set di dll s e singolo file exe (che probabilmente sta chiamando questi dll s da solo). E i possibili approcci potrebbero essere: usare la dichiarazione Process.Start per eseguire un eseguibile e catturarne l'output. E un altro è quello di chiamare direttamente dll.

Sto cercando di capire quale approccio dovremmo usare.

Da una parte chiamare eseguibile è semplice, ma dall'altra non sembra robusto.

Da un lato chiamando dll sembra più giusto modo di fare il lavoro, ma dall'altra - potrebbe essere il compito molto complesso per fornire C# vincolante per tutte le funzioni che abbiamo in codice nativo C.

Ma ho bisogno di analisi più approfondite su questo argomento per prendere una decisione definitiva. Qualcuno ha di fronte la stessa domanda prima, forse potresti condividere la tua scoperta.

Sarebbe molto utile!

EDIT: Sto parlando di conversione video in questo caso particolare. Ho bisogno di ottenere il flusso video da utente e convertirlo in un formato video per tutti. È possibile chiamare ffmpeg per fare il lavoro, e tutto è OK fino a quando qualcosa va storto e ho bisogno di riavviare la codifica o fare qualsiasi azione. Non potrei stimare quanto tempo ci vorrà e se avrò bisogno di convertire più video in parallelo ffmpeg non sarà così flessibile, come ho intenzione di essere ...

Almeno come lo vedo ora. Forse arriveranno altri problemi mentre scrivo.

Answer 1

ci sono diverse considerazioni:

1. Avete il sorgente per dll?
2. Quanto intendi chiamare quelle DLL?
3. Quanto sono complesse le API delle DLL e il tuo utilizzo?

A seconda delle risposte.

creare associazioni se:

• Tu chiamerai spesso DLL. La chiamata diretta è molto più veloce.
• Hai la fonte e controlla quanto sono bravi. In caso contrario, potresti avere grossi problemi con perdite di memoria, convocazione di convenzioni ecc.
• Le API di DLL non sono troppo complesse, quindi non dovrai inviare loro oggetti C++, ecc. O implorare molto lavoro già fatto in exe.

Utilizzare eseguibili:

• Se avete bisogno di eseguire loro solo di tanto in tanto. L'overhead di creare un altro processo non ha importanza per te.
• Se non sei sicuro della qualità del codice.Sarà molto più sicuro e robusto per il tuo codice, non per caricare alcune dll mal implementate. Puoi sempre provare a eseguire .exe più volte se si verifica un problema. Ma una DLL blocca la tua app, non puoi fare nulla.
• Se l'API è molto complessa, ed exe ha un sacco di funzionalità, che dovrete reimplementare.

Answer 2

Direi che ciò dipenderà dalla quantità di granularità che il tuo codice si aspetta in termini di supporto API dalla libreria.

Se l'eseguibile incapsula i flussi di lavoro abbastanza bene per voi, è possibile trarre vantaggio dalla semplicità di richiamo dell'eseguibile.

Inoltre, poiché si parla di codice C nativo, l'aggiunta di riferimenti DLL significherebbe dover gestire il codice non gestito, che personalmente non utilizzerei a meno che non ci sia alcuna opzione per me.

Answer 3

Se la DLL è ben scritta e senza perdite di memoria, è meglio utilizzare la DLL, poiché non richiede un nuovo overhead per la creazione del processo.

Answer 4

Direi che tutto dipende dalle tue esigenze, dal tempo, dalla stabilità dell'output del tuo file exe e dalla facilità con cui può essere analizzato. Entrambi i modi sono fattibili.

Ad esempio, Mercurial considera la console come il modo principale di interagire con esso, anche se si può usare direttamente il suo codice Python.

D'altra parte, chiamare le funzioni C da C# è abbastanza semplice, quindi questa potrebbe essere un'opzione. Se, tuttavia, è necessario mappare centinaia di funzioni C, è necessario chiedersi se si ha il tempo di farlo.

Answer 5

EXE C'è una singola voce principale da chiamare, quindi non è possibile chiamare direttamente le funzioni. Quando si chiama un exe, verrà creato un nuovo processo nel thread di ingresso nel contesto del thread principale di quel processo.

DLL offre una maggiore flessibilità per le funzioni di chiamata direttamente v'è un punto di ingresso per la funzione del sistema carica una DLL nel contesto di un thread esistente

quindi chiamando DLL è molto meglio per le risorse computazionali, e di fornire più flessibilità. considerando che è possibile chiamare una DLL dal codice gestito e non gestito, e chiamare chiamate dll gestite e non gestite da C#

Se la DLL ha un'interfaccia come è possibile aggiungere un refrence direttamente, e se non ce l'hai si può ancora definirla come qui di seguito

[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 parole semplici si importa il DLL e mappare i parametri ai tipi .NET utilizzando smistamento

Answer 6

risposta dipende dal modo in applicazione esterna utilizza è DLL .:

• Call exe, se chiama più funzioni dll, più volte e il suo processo di business è grande e complicato - non si vuole reimplementare tutta la logica exe nel codice C#.
• Call dll direttamente, se exe chiama solo una-due funzioni da dll, l'ordine di chiamata ei parametri sono ben noti o assenti.

In generale, preferisco chiamare direttamente dll, perché questo ha eliminato un sacco di spese generali e possibili problemi con il nuovo processo di generazione e l'elaborazione dell'output. E non temere il codice nativo, se le tue funzioni di dll sono semplici allora con PInvoke sarai in grado di chiamare facilmente quelle funzioni.