Costruisci una dll nativa o .net dll da usare indipendentemente in entrambi i set-up

4

Ecco una semplice domanda (tipo di), ma sto facendo fatica a prendere una decisione. Innanzitutto, una storia su come sono arrivato ad avere questo problema. Nel mio nuovo lavoro, dobbiamo utilizzare un'API di terze parti per comunicare con il loro database proprietario (si tratta di tecnologie di produzione). Questa API viene fornita con un esempio c molto semplice (non semplice sintassi;)) su come utilizzare questa API. Le funzioni non hanno documentazioni e la sintassi è spessa, dal momento che probabilmente è stata creata nel corso dell'ultimo secolo, quindi i parametri hanno nomi brevi e non significativi uguali ai nomi delle funzioni.

Pochissimi aiuti si trovano sul Web e la società stessa non può davvero aiutarci. Nel web, la piccola briciola trovata riguarda persone che non sono in grado di tradurle in una chiamata di lingua più semplice (come VB6). Le persone prima di me qui hanno cercato di usarlo, senza successo.

La buona notizia è che sono stato in grado di fare in modo che l'esempio funzionasse e modificato per soddisfare le nostre esigenze di base per l'invio o la lettura dei dati. Ho avvolto queste nuove versioni in una dll di assembly c ++ / CLR, per usarle in c #, che è la nostra lingua quasi corrente (Sì, si muove lentamente in questo mondo)

A seconda della versione del software che utilizziamo (ogni cliente che abbiamo può avere impostazioni diverse, dalla legacy alla nuova configurazione). Questo può influire su quale linguaggio usiamo. Quindi mi è stato chiesto di provare a rendere disponibile la mia DLL in native & impostazione gestita.

Quindi, ecco la mia domanda. Dovrei lasciare la mia DLL per avere una firma gestita e se deve essere usata in vb6, assicurati che sia capito come farlo funzionare in modalità nativa (che ho bisogno di imparare), o dovrei fare una dll nativa e fare P / Invoke in ambiente gestito? O dovrei costruire due dll distinte? IMO, lo terrei come una DLL gestita, ma mi chiedevo se fosse il modo migliore per farlo?

In un'ultima nota, la versione corrente è una build v.1 per mostrare come possiamo usarla e iniziare a usarla velocemente. Scrivere questo mi fa capire che ho bisogno di costruire un'interfaccia! :). Ho intenzione di ricostruire l'intero programma, ma le chiamate dell'API saranno sempre alla loro dll nativa, a meno che non abbiano .net SDK in arrivo, ma non ne hanno ancora parlato.

    
posta Shuryno 03.05.2012 - 16:17
fonte

1 risposta

3

Ci sono due svantaggi nel mantenere solo la DLL gestita:

a) avrai bisogno di .NET Framework sul computer di destinazione

b) ci saranno due livelli di marshalling tra un chiamante non gestito e il codice che hai incapsulato: un COM Callable-Wrapper tra il chiamante nativo e l'interfaccia COM del tuo .NET Assembly e la transizione gestita-non gestita tra il tuo wrapper e il codice interno: questo potrebbe essere un grave problema di prestazioni se esegui il marshalling molto spesso e potrebbe essere complesso se l'interfaccia con i chiamanti è ampia.

Se nessuno di questi è un problema reale (ad esempio l'aggiunta di CCW in termini di prestazioni e complessità), non hai altri incentivi diretti che possa vedere per modificare la tua soluzione corrente.

Per quanto riguarda l'estensibilità, se si intende aggiungere codice gestito al wrapper - se è necessario integrare la soluzione che si sta completando e occorre aggiungervi elementi a basso costo del codice gestito, allora si ' sono praticamente bloccati con la DLL gestita, perché presumibilmente sia i chiamanti VB6 sia i chiamanti gestiti necessiterebbero della nuova funzionalità. Se, invece, è necessario aggiungere codice nativo, è comunque possibile aggiungerlo alla parte CLI non gestita della DLL gestita.

    
risposta data 03.05.2012 - 17:56
fonte

Leggi altre domande sui tag