Ho letto molte domande e risposte che indicano che se voglio collegare il mio progetto C# alle librerie native, non posso usare il target della piattaforma AnyCPU ma devo creare build separati a 32 e 64 bit, ciascuno collegato alla DLL nativa del testimone appropriato.In che modo le classi di .NET Framework fanno riferimento a DLL Windows native senza diventare specifici per i test di verifica?
Questo mi fa pensare a come gli assembly .NET Framework sono o almeno sembrano essere creati per AnyCPU. Cioè, quando si aggiunge un riferimento alla mia applicazione GUI, perché non devo scegliere la versione a 32 o 64 bit di System.Windows.Forms? Ho pensato che potesse trattarsi solo di qualche magia di Visual Studio che sarebbe stata risolta nella sottodirectory GAC appropriata (GAC_32 o GAC_64), ma ho cercato System.Windows.Forms.dll nel GAC e l'ho trovato in:
C: \ Windows \ Microsoft.NET \ assembly \ GAC_MSIL \ System.Windows.Forms \ v4.0_4.0.0.0__b77a5c561934e089 \ System.Windows.Forms.dll
Nota "GAC_MSIL". In che modo questa DLL riesce a racchiudere un'API nativa a 32 bit e rimanere linkabile in un'applicazione a 64 bit? E perché non posso usare una strategia simile per creare una singola DLL C# che si collega a una libreria nativa a 32 bit e che sia ancora eseguibile in modalità 64 bit?
È perché gli assembly .NET non sono compilati nelle istruzioni del processore. Si compilano in una [lingua intermedia] (https://en.wikipedia.org/wiki/Common_Intermediate_Language), che quindi viene eseguita attraverso il framework .NET e viene tradotta in istruzioni del processore in fase di runtime. – pquest
@pquest, penso di capirlo molto ma non vedo come risponde alla mia domanda. Puoi elaborare? – adv12
Basta caricare la versione corretta della dll nativa prima di chiamare qualsiasi api? Ecco come funziona la maggior parte degli assembly che funziona in modo nativo. –