Voglio chiamare una DLL nel mio linguaggio di programmazione di "scelta". La documentazione che circonda questo indica chiaramente che deve essere una DLL a 32 bit scritta in C, C ++ o Delphi. Ma volevo chiamare una DLL scritta in C #. Va anche detto che la modalità di chiamata predefinita è cdecl .
Quindi la mia domanda è: perché dovrebbe essere così? C'è un modo per farlo pensare che una DLL C # è stata scritta in C, C ++ o Delphi?
Questo stesso problema è ciò che la COM è stata progettata per affrontare. Lo lascerò al mio buon amico Jeremiah Morrill per spiegare qual è il problema:
I explained briefly how simple exporting regular “C” methods can be to share code between DLLs and the application. I also explained how C++ classes get flattened and compiled down and also how they are seen to your CPU (more or less). If C++ classes just get compiled to static “C” methods, which can be exported from our DLL, is that not sufficient to reuse and share classes across DLLs? Yes…but not without some major caveats as this would come at a cost.
The first disadvantage of exporting a C++ class is you must use the same C runtime in all DLLs/exe involved. So if one DLL used MSVCRT7, the caller of the DLL must be using MSVCRT7. The reason is different versions of C runtimes manage the heap differently, so if DLL A tried to free resources allocated by DLL B, memory corruption can occur.
The second disadvantage is the same compiler version must be used. This is because different compilers mangle names differently. Name mangling differences among compilers ensures a DLL built with Microsoft would have completely different symbol names than a DLL built with GCC. So when linking of your code occurs, the linker might be looking for “??4MyWidget…” when the export is really “MyWidget__Fi…”
Third, if a large change of the base classes in DLL A are made, even without breaking API, then DLL B that uses the base classes must be recompiled.
Forth [sic], if you take the last three disadvantages into consideration, we have a very tight coupling between our DLLs. This inhibits reusability of the module.
Sometimes these issues are not an issue for a given project. This is usually acceptable when the project is small, or an in house utility. That’s totally fine. But let’s pretend Microsoft ignored these problems. All developers would have to use the same compiler version. Applications would have to be written for very specific versions of Windows. This would be a complete nightmare for everyone.
Osservando questi problemi, COM è una soluzione semplice per risolverli. Esponendo il tuo C # dll a COM, puoi chiamarlo da qualsiasi altro linguaggio compatibile con COM.
Il tuo linguaggio di scelta supporta il richiamo di qualsiasi DLL nativa scritta in qualsiasi lingua. Non è veramente limitato a quelli creati con C, C ++ o Delphi. Ad esempio, puoi chiamare anche le DLL di Fortran.
Il problema è che la DLL C # è una DLL gestita. Questa è una bestia completamente diversa da una DLL nativa. Dovrai inserire un livello di bridging tra C # e il tuo codice. Le esportazioni non gestite di Robert Giesecke sono un modo semplice per farlo.