C# dll non gestito esportazione (come funziona) librerie

Question

ho trovato che esportare gestito codice come non gestito in modo da poter utilizzare per unmanaged linguaggi come C/C++. Ma non ho trovato nulla che spiegasse come è fatto (che è quello a cui sono più interessato)

Sto cercando informazioni, tutorial, articoli, fonti di codice o qualsiasi cosa possa aiutarmi a capire come questo funziona

una nota a parte, se hai trovato qualche ganci/deviazioni risorse nei segnalibri mi piacerebbe leggere anche loro :)

Grazie in anticipo e hanno una splendida giornata.

Answer 1

Pubblicherò una risposta, raccogliendo i commenti che ho scritto.

La libreria più famosa per farlo è (come oggi) UnmanagedExports. La sua pagina è https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports. Purtroppo non esiste un codice sorgente disponibile, ma è concesso in licenza con la licenza MIT, quindi probabilmente è ok usare IlSpy per dare un'occhiata a questo.

Ci sono alcuni riferimenti su come è fatto.

Ci sono almeno due articoli su Codeproject: How to Automate Exporting .NET Function to Unmanaged Programs che sembra essere per .NET 2.0 e Unmanaged code can wrap managed methods che purtroppo riguarda .NET 1.1.

C'è qualche riferimento nel libro Expert .NET 2.0 IL Assembler intorno pagina 384.

si può sicuramente fare un'altra cosa: osservare ciò che UnmanagedExports fare: UnmanagedExports alla fine è "composto" di due parti: un insieme RGiesecke.DllExport.Metadata.dll contenente una " "stupido" attributo DllExportAttribute più due assembly (che sul mio computer installa il nuget nella cartella \ UnmanagedExports.1.2.6 \ tools): RGiesecke.DllExport.dll e RGiesecke.DllExport.MSBuild.dll. L'installatore NuGet di UnmanagedExports aggiunge alcune righe alla csproj, come:

<Import Project="packages/UnmanagedExports.1.2.6/tools/RGiesecke.DllExport.targets" Condition="Exists('packages/UnmanagedExports.1.2.6/tools/RGiesecke.DllExport.targets')" /> 

che causano l'esecuzione della classe RGiesecke.DllExport.MSBuild.DllExportAppDomainIsolatedTask contenuta nell'assieme RGiesecke.DllExport.MSBuild.dll. Questa classe, che utilizza Mono.Cecil, riscrive l'assembly eseguendo un po 'di reweaving del codice. Questo programma chiama semplicemente ildasm per generare la sorgente del codice, modifica la sorgente del codice e quindi utilizza ilasm per generare il dll/.exe "originale". Quindi in poche parole, generare due gruppi, uno con la <Import /> e un altro con la <Import /> commentata, poi fare un

ildasm yourdll.dll /out=source.il 

di entrambi i file e confrontarlo con il vostro operatore di confronto di file preferito.

Un altro collegamento interessante è here. Ci sono alcuni commenti su come farlo funzionare su x64.

Se dovessi creare qualcosa di simile, probabilmente proverei ad integrarlo a Fody. In questo modo avrei l'intera attività post-compilazione gratuitamente (perché è fatta da Fody)

Non può essere fatto con Mono.Cecil ...Mono.Cecil non può scrivere assiemi in modalità mista (necessari per esportare simboli). Devi usare lo stesso "trucco" usato da UnmanagedExports (e dai vari altri esempi) ... Generare il file IL, modificarlo (è un file di testo in un formato fisso ... abbastanza facile da modificare), -generare il file .dll/.exe.

Answer 2

Ecco il codice sorgente delle esportazioni non gestiti mantenuto su GitHub:

https://github.com/3F/DllExport

esportazioni non gestiti deve essere fare in sostanza quello che C++/CLI compilatore ha a che fare per PInvoke inverso.