Perché gli sviluppatori .NET offrono versioni a 32 bit / 64 bit degli assembly .NET?

Question

Ogni tanto vedo entrambe le versioni x86 e x64 di un assembly .NET. Considerare la seguente web part per SharePoint . Perché lo sviluppatore non dovrebbe offrire una sola versione e lasciare che il compilatore JIT risolva il resto? Quando vedo l'offerta di questi tipi è solo che lo sviluppatore ha deciso di creare un'immagine nativa utilizzando uno strumento come ngen per evitare una SIC?

Qualcuno per favore aiutami qui, mi sento come se mi mancasse qualcosa di interessante.

Aggiornamento

Da quello che ho ottenuto di seguito, vengono offerti build sia x86 che x64 perché uno o più dei seguenti motivi:

1. Lo sviluppatore voleva evitare JIT e ha creato un'immagine nativa del suo codice, indirizzando una determinata architettura utilizzando uno strumento come ngen.exe.

2. L'assembly contiene chiamate COM specifiche della piattaforma e quindi non ha senso costruirlo come AnyCPU. In questi casi build che hanno come target piattaforme diverse possono contenere codice diverso.

3. L'assembly può contenere chiamate Win32 usando pinvoke che non verrà rimappato da un JIT e quindi la build dovrebbe essere indirizzata alla piattaforma a cui è vincolata.

Answer 1

Se utilizzano API specifiche non.Net, potrebbero esserci due basi di codice per questo, un esempio perfetto sono i controlli COM.

ngen è anche un'altra ottima ragione per questo, come hai menzionato.

Answer 2

Quando compili un'applicazione .net devi scegliere un Target piattaforma nelle Impostazioni di costruzione. Le scelte sono AnyCPU, x86 e x64.

Un bug comune è specificare AnyCPU in un progetto che include DLL native compilate per x86. Ciò comporterà errori quando eseguito su macchine a 64 bit, un buon motivo per testare su una macchina a 64 bit.

Pertanto, per supportare le persone che sono costrette dalle loro altre dipendenze a costruire direttamente per x86 o x64, l'assemblaggio offre entrambi.

Answer 3

COM gestisce il marshalling e il unmarshaling oltre i limiti di 32/64 bit. Tuttavia, non fornisce alcun supporto per il caricamento del tipo alternativo di binario nella larghezza del puntatore errata dell'appartamento.

Molti assembly si basano sul codice nativo (la maggior parte dei driver SQL sono scritti in C o C ++, ad esempio). Questo è incredibilmente evidente per qualsiasi cosa usi p / invoke; pertanto, avere diverse larghezze di puntatore compilate e distribuite significa che il pacchetto per la versione a 64 bit molto probabilmente contiene DLL native a 64 bit e la versione a 32 bit contiene probabilmente DLL native a 32 bit. Questo è il caso anche se le versioni a 32 e 64 bit dell'assembly sono compilate dallo stesso codice.

csc produrrà le immagini native (pre-JITted) se lo chiedi.