[C++] Utilizzo di una DLL scritta in C#

[Mario Turbo]

Ho la necessità di scrivere una DLL in C# e di fornirla ad un utilizzatore che sviluppa in C.
Per fare un test ho utilizzato una DLL semplicissima, questo è il sorgente scritto in C#:

namespace Test_1
{
public class Class1
{
public static int Add(int a1, int a2)
{
return a1 + a2;
}
}
}

Ho fornito all'utilizzatore la Test_1.dll indicando il punto di ingresso Add(int a1, int a2).

Quando si richiama la dll in C appare un avviso che avverte -- Impossibile trovare un punto di ingresso con nome 'Add' nella DLL 'Test_1.dll' --

Dove sbaglio ?
Qualcuno mi può aiutare ?

[linoma]

Prova a leggere le funzioni esportate della DLL, molto probabilmente, se la funzione è esportata (?), avra' qualche carattere di pre/post fisso.

[MItaly]

Le dll C# sono bestie completamente diverse dalle dll native... una dll C# è un assembly .NET, che un'applicazione nativa non sa minimamente come gestire. Non mi risulta che da C# sia possibile esportare in maniera semplice funzioni come farebbe una dll nativa C.
C# fornisce però un metodo semplice per esportare i propri tipi e metodi tramite COM, applicando sui tipi da esportare un particolare attributo che ora come ora non ricordo e forse creando un tlb per l'assembly; d'altra parte usare COM dal C è un lavoraccio che sconsiglio.
Un'altra alternativa è creare un assembly misto C++/CLR - C++ nativo, che faccia da "ponte" tra la parte .NET e la parte nativa: da un lato la parte "nativa" della dll esporta le funzioni richiamabili dal C, dall'altra la parte .NET richiama i pezzi scritti in C#.
Esiste poi la possibilità di richiamare direttamente metodi .NET dal C++ (e forse anche dal C, con le dovute rotture di scatole aggiuntive) usando una dll COM del .NET Framework con cui chiamare (in maniera piuttosto scomoda) i vari metodi dell'assembly .NET che si vuole caricare; il procedimento non è semplice e coinvolge un sacco di "boilerplate code", che tuttavia può essere "nascosto" in una piccola libreria. In questo articolo è spiegato il metodo "normale" e viene fornita una piccola libreria che semplifica la questione.

In ogni caso, se i tuoi client sono soprattutto codice non gestito e non si vuole usare COM scrivere una dll in C# non è una buona idea.

[Freax]

Originariamente inviato da MItaly
Le dll C# sono bestie completamente diverse dalle dll native... una dll C# è un assembly .NET, che un'applicazione nativa non sa minimamente come gestire. Non mi risulta che da C# sia possibile esportare in maniera semplice funzioni come farebbe una dll nativa C.
C# fornisce però un metodo semplice per esportare i propri tipi e metodi tramite COM, applicando sui tipi da esportare un particolare attributo che ora come ora non ricordo e forse creando un tlb per l'assembly; d'altra parte usare COM dal C è un lavoraccio che sconsiglio.
Un'altra alternativa è creare un assembly misto C++/CLR - C++ nativo, che faccia da "ponte" tra la parte .NET e la parte nativa: da un lato la parte "nativa" della dll esporta le funzioni richiamabili dal C, dall'altra la parte .NET richiama i pezzi scritti in C#.
Esiste poi la possibilità di richiamare direttamente metodi .NET dal C++ (e forse anche dal C, con le dovute rotture di scatole aggiuntive) usando una dll COM del .NET Framework con cui chiamare (in maniera piuttosto scomoda) i vari metodi dell'assembly .NET che si vuole caricare; il procedimento non è semplice e coinvolge un sacco di "boilerplate code", che tuttavia può essere "nascosto" in una piccola libreria. In questo articolo è spiegato il metodo "normale" e viene fornita una piccola libreria che semplifica la questione.

In ogni caso, se i tuoi client sono soprattutto codice non gestito e non si vuole usare COM scrivere una dll in C# non è una buona idea.

siccome ho da poco iniziato il C# mi intrometto per commentare: in pratica al C servirebbe un traduttore in linguaggio macchina ovvero un JIT? Quella dll è adesso solo bytecode in C#, giusto?

[MItaly]

Il problema non è solo quello, quanto piuttosto la diversa struttura tra le dll unmanaged e quelle managed. Le dll managed in realtà non esportano alcuna funzione, ma dentro alla classica struttura "PE" inglobano tutti i metadati .NET che consentono alla CLR di sapere che tipi e che metodi sono contenuti. Tutto questo non ha equivalente unmanaged: una dll "classica" si limita ad esportare delle funzioni (di cui tra l'altro si sa solo il nome), per cui non sarebbe possibile effettuare un mapping "automatico" tra metodi .NET e funzioni da esportare.
Vale comunque anche quello che dici, ovvero per far andare la dll .NET bisogna caricare il JIT e la CLR, cosa che comunque con il marshaling COM si fa al caricamento della dll.