Diciamo che sto accedendo a una libreria di terze parti, per la quale la documentazione afferma che posso usare pInvoke o creare una libreria di interoperabilità e usare COM. Qual è la differenza tra queste due tecniche e perché potrei sceglierne una rispetto all'altra?Qual è la differenza tra pInvoke e COM Interop?
P/Invoke viene utilizzato per chiamare le API plain-C (come la maggior parte dell'API Win32). L'interoperabilità COM viene utilizzata per chiamare oggetti COM.
È possibile creare un wrapper COM C++ attorno a un'API C e quindi utilizzare l'interoperabilità COM per chiamare il proprio wrapper se il numero di chiamate API è relativamente elevato (ed è possibile utilizzare il wrapper COM per incapsularle in una o due chiamate). Questo perché l'interoperabilità nativa gestita può essere relativamente costosa ed è bene ridurre al minimo il numero di transizioni. Anche se in realtà direi che usare C++/CLI per creare il wrapper sarebbe probabilmente un po 'più amichevole per il lato C# della cosa (guardando SlimDX, ad esempio, che è un wrapper C++/CLI attorno a un'API COM (DirectX)).
Detto questo, a meno che non si abbia un problema di prestazioni specifico, vorrei semplicemente utilizzare qualsiasi metodo sia più naturale per l'API che si sta tentando di chiamare: se si tratta di un'API C (come l'API Win32), utilizzare P /Invocare. Se è basato su COM, utilizzare l'interoperabilità COM.
PInvoke utilizza il meccanismo di collegamento dinamico per portare il codice esterno nel processo di esecuzione. Le librerie di collegamenti dinamici (DLL) devono avere la stessa architettura di destinazione dell'applicazione chiamante, pertanto non è possibile effettuare chiamate incrociate da 64-bit a 32-bit o viceversa. Invece la DLL viene mappata nello spazio degli indirizzi del chiamante ed eseguita in corso.
COM, DCOM, COM + e ActiveX si basano tutte su librerie di comunicazioni interprocesso, ma a volte possono essere convertite in un semplice carico DLL. Gli oggetti collegati COM sono correlati, ma non identici agli oggetti CORBA, ma mentre CORBA ha evoluto il proprio object locator, l'implementazione COM è ancora liberamente basata sulle librerie RPC e XDR di Sun Microsystems con estensioni per le funzionalità orientate agli oggetti di COM. Gli oggetti COM non sono referenziati dalla DLL, ma da un GUID che viene utilizzato per cercare la classe dell'oggetto e interrogare le sue interfacce. Il codice oggetto di solito viene eseguito in un processo separato ed eventualmente su un server separato.
Quindi stai dicendo che sotto la cappa, gli interpelli COM stanno facendo da soli gli stessi ragni? E che COM è solo un involucro amichevole? – Grant
No, COM interop e P/Invoke sono diversi e uno non è implementato nei termini dell'altro. Quello che stavo dicendo nel mio secondo paragrafo è che se l'API C è "chatty" e richiede molte chiamate di funzione, potresti creare un wrapper COM (in C++) e chiamare * il wrapper * da C# per ridurre il numero di transizioni native. Sospetto che sia ciò che suggerisce la documentazione per la tua biblioteca. –