perché gli assiemi .net differiscono per le diverse architetture?

Question

Posso costruire il mio progetto C# per x86 e x64. Perché? Ho pensato che generi un codice speciale che non è affatto specifico della piattaforma.

Answer 1

In primo luogo, vorrei essere sincero e dire che non conosco tutta la storia qui, ho intenzione di rispondere con quello che penso di sapere. Cancellerò felicemente o cambierò la mia risposta se qualcuno può dirmi dove ho sbagliato.

Il modo in cui l'ho capito, questa impostazione è una bandiera che dice "l'assembly dovrebbe essere eseguito in questo tipo di architettura". Questo è per l'impostazione x86 e x64. L'impostazione MSIL/.NET sta solo dicendo "Non mi interessa, posso correre su entrambi, quindi scegli quello che è ottimale o disponibile".

Ad esempio, è possibile effettuare chiamate alle funzioni API Win32 tramite P/Invoke, nel qual caso l'assembly non funzionerà su x64 e si dovrebbe contrassegnarlo come x86.

Quindi, se la mia comprensione è corretta, ecco come i tre bandiere fanno la corsa di montaggio (nota, è l'assemblaggio principale, l'assemblea di programma, che impone questo, non ogni singola assemblea per se stessi) su diverse piattaforme:

Setting  x86  x64 <-- Platform (CPU/OS) 
MSIL/.NET  32-bit 64-bit 
x86   32-bit 32-bit 
x64   N/A (*) 64-bit 

L'assembly N/A per x64 su x86 significa che l'assembly non verrà caricato e otterrete un'eccezione se provate.

Si noti inoltre che le impostazioni in conflitto che coinvolgono x86 e x64 faranno crashare il programma in un punto o nell'altro. Se l'assembly principale è impostato su x86, verrà eseguito come processo a 32 bit su un sistema operativo a 32 bit e 64 bit e qualsiasi tentativo di caricamento degli assembly contrassegnato come x64 avrà esito negativo. Allo stesso modo, se l'assembly principale è impostato su x64, verrà eseguito solo sul sistema operativo a 64 bit e qualsiasi tentativo di caricamento di un assieme impostato su x86 avrà esito negativo.

Un assembly eseguibile principale MSIL verrà eseguito come 32-bit su un sistema operativo a 32 bit (come se fosse impostato su x86, con il punto di errore sopra riportato) e come 64-bit su un sistema operativo a 64 bit (come se fosse impostato su x64, con il precedente punto di errore.)

Ovviamente In genere, si desidera andare con l'impostazione MSIL se non si sta chiamando gli assembly contrassegnati come qualcosa di specifico, e come lungo dato che non stai facendo P/Invoke che non è portabile su 32-bit e 64-bit (non ho idea se funzioni, se le funzioni P/Invoke to win-api verranno mappate su una dll bitizzata correttamente o no.)

Dal riferimento s sono puntatori, e i puntatori sono memorizzati come indirizzo nativo x-bit sulle due piattaforme, a seconda della quantità di riferimenti che si hanno, è possibile che contatterà solo andando con MSIL. Tuttavia, dovresti verificare che questo sia un problema prima di apportare una modifica alle tue impostazioni.

Answer 2

Questo flag è importante per i file EXE. Decide se si esegue un processo a 32 o 64 bit. Se si utilizzano DLL "native" dal proprio codice .NET, è necessario seguire l'architettura per tali DLL.

"Any CPU" nei file EXE selezionerà x64 se disponibile.

Answer 3

Credo che il motivo per cui ci sono obiettivi diversi è dovuto alla dimensione dei tipi scalari. Penso che influenzi anche il modo in cui vengono gestiti gli oggetti COM.

Ho una situazione in cui dispongo di una libreria .NET di terze parti che, se utilizzata in un'applicazione a 64 bit, il programma non riesce quando si chiama nella libreria, quindi devo limitare la modalità solo a 32 bit.

Answer 4

Prima di tutto, l'impostazione Piattaforma di destinazione per x86 su progetto exe è molto utile quando si esegue il debug il progetto su una versione a 64 bit di Windows. Il debugger VS2005/8 non supporta Modifica + Continua su codice a 64 bit.

scelta x86 nella tua build di rilascio è qualcosa che si deve fare se si programma ha una dipendenza da un componente che funziona solo in codice a 32 bit. Questo non è raro, ci sono tonnellate di componenti COM là fuori che non hanno mai e mai saranno portati al codice non gestito a 64-bit. Un classico esempio è il motore di database Microsoft Jet.

scelta x64 è molto insolito, non c'è molto codice non gestito che è disponibile solo nella versione a 64 bit. Notevole è che riceverai avvertimenti quando costruisci il tuo assembly, ci sono diversi assembly di framework .NET che contengono codice non gestito; solo le versioni a 32 bit sono disponibili in c: \ windows \ microsoft.net. È possibile ignorare tranquillamente tali avvisi, le versioni a 64 bit sono effettivamente installate nel GAC.

Una ruga quando si seleziona x64 è che il compilatore C# 3.0 emetterà un binario che chiede a Windows di creare il thread di avvio con una dimensione dello stack di 4 megabyte, invece del 1 megabyte predefinito. Questo è un po 'giustificato, il codice a 64 bit ha bisogno di più stack per memorizzare puntatori e indirizzi di ritorno.

Infine, l'SDK di Windows ha lo strumento Corflags.exe a disposizione per passare il bit-ness di un insieme dopo che è stato costruito. L'opzione/32BIT + equivale all'impostazione di Platform Target su x86. L'utilizzo di/32BIT- assicura che l'assembly verrà eseguito in modalità a 64 bit su un sistema operativo a 64 bit. La modifica della dimensione dello stack predefinita è possibile con lo strumento Editbin.exe.