Ci sono delle considerazioni da prendere durante l'esecuzione del programma .net su x64 vs x86?
Domanda
Credo che il tipo di architettura (x86 vs x64) sia stato estratto per te durante la creazione di programmi .Net, ma ci sono altre considerazioni che possono causare problemi?
Soluzione
Attenzione alle librerie COM di terze parti o alle librerie .NET di terze parti che effettuano segretamente chiamate win32. È lì che abbiamo avuto i nostri maggiori mal di testa.
Altri suggerimenti
Dal doco MSDN , tra le altre considerazioni:
In molti casi, gli assembly funzioneranno allo stesso modo sul CLR a 32 o 64 bit. Alcuni motivi per cui un programma si comporta diversamente quando viene eseguito dal CLR a 64 bit includono:
Le strutture che contengono membri che cambia dimensione a seconda della piattaforma, come qualsiasi tipo di puntatore.
Aritmetica del puntatore che include dimensioni costanti.
Invoke o COM errato della piattaforma dichiarazioni che utilizzano Int32 per gestisce invece di IntPtr.
Trasmissione di IntPtr a Int32
Inoltre, le posizioni dei file predefinite.
Questo articolo ha molti buoni problemi da tenere presente: http://osnews.com/story/20330/Windows_x64_Watch_List
Personalmente, il mio capo ha un computer Vista a 64 bit e programma in una modalità a 32 bit. Abbiamo riscontrato i seguenti problemi:
-
Il registro per le app a 32 bit viene nascosto (una specie di) in una cartella Wow6432Node. Non tutte le app a cui sei abituato a trovare un percorso nel registro si troveranno in quel nodo (ad esempio SQL Server non lo farà).
-
SysWow64 nella cartella C: \ Windows può causare problemi di DLL non presenti dove sono necessari (abbiamo riscontrato questo problema con un componente di licenza di terze parti).
-
A volte i file necessari sono in " C: \ Programmi (x86) " ;, piuttosto che " C: \ Programmi " ;. Fa anche schifo.
-
La lettura e la scrittura di valori a 64 bit non è thread-safe su una piattaforma a 32 bit. La lettura di un valore a 64 bit richiede due operazioni che potrebbero essere interrotte da un interruttore di contesto. Vedi l'articolo MSDN su Threading.Interlocked.Read per ulteriori informazioni.
-
Inoltre, sono completamente d'accordo con torial 's risposte ! : -)
MSDN ha pubblicato un piccolo documento riguardante i problemi di porting delle applicazioni a 32 bit su un ambiente di esecuzione a 64 bit.
http://msdn.microsoft.com/en-us/library /ms973190.aspx
Altri due blogger avevano scritto in precedenza sullo sviluppo a 64 bit mentre lavoravano nel team CLR
x64 ti consentirà di indirizzare più memoria, ma dato lo stesso codice, utilizzerà più memoria di x86.
Nella mia esperienza il porting di un'applicazione Asp.NET era sostanzialmente impeccabile. Esegui su una macchina a 32 bit e su 64 bit e non si verificano problemi, oltre a disporre di più memoria disponibile. Ciò accade perché molti dei problemi già menzionati (registro, threading e così via) sono stati gestiti da Asp.NET e devi correggerli correttamente per l'esecuzione nell'ambiente Asp.NET.
Il lato client (modulo Windows) è successo lo stesso, ma se hai usato un po 'di "non sicuro" API per ottenere cartelle speciali o accesso al registro, quindi può verificarsi qualche problema, come già indicato.
Saluti Massimo