Qual è lo scopo dell'impostazione "Prefer 32 bit" in Visual Studio e come funziona effettivamente?

204

Inserisci qui la descrizione dell'immagine

Non mi è chiaro come il compilatore saprà automaticamente compilare per 64 bit quando sarà necessario. Come fa a sapere quando può targetizzare con sicurezza a 32 bit?

Sono principalmente curioso di sapere come il compilatore sa quale architettura scegliere come target durante la compilazione. Analizza il codice e prende una decisione in base a ciò che trova?

— Aaron
fonte

stackoverflow.com/questions/7508965/...

— Marc Gravell

Ah grazie. Non l'ho visto prima. Sono ancora curioso di sapere come il compilatore sappia automaticamente quale architettura scegliere come target. Qualche idea?

— Aaron il

Risposte:

219

Microsoft ha un post nel blog Cosa significa AnyCPU a partire da .NET 4.5 e Visual Studio 11 :

In .NET 4.5 e Visual Studio 11 il formaggio è stato spostato. L'impostazione predefinita per la maggior parte dei progetti .NET è di nuovo AnyCPU, ma ora c'è più di un significato per AnyCPU. Esiste un sottotipo aggiuntivo di AnyCPU, "Qualsiasi CPU a 32 bit preferita", che è il nuovo predefinito (nel complesso, ora ci sono cinque opzioni per l'opzione del compilatore C # / platform: x86, Itanium, x64, anycpu e anycpu32bitpreferred ). Quando si utilizza il sapore "Prefer 32 bit" di AnyCPU, la semantica è la seguente:

Se il processo viene eseguito su un sistema Windows a 32 bit, viene eseguito come processo a 32 bit. IL viene compilato in codice macchina x86.

Se il processo viene eseguito su un sistema Windows a 64 bit, viene eseguito come processo a 32 bit. IL viene compilato in codice macchina x86.

Se il processo viene eseguito su un sistema ARM Windows, viene eseguito come processo a 32 bit. IL viene compilato in base al codice macchina ARM.

La differenza, quindi, tra "Qualsiasi CPU a 32 bit preferita" e "x86" è solo questa: un'applicazione .NET compilata per x86 non funzionerà su un sistema ARM Windows, ma un'applicazione "Qualsiasi CPU a 32 bit preferita" funzionerà correttamente.

— Lex Li
fonte

+1. Inoltre, la casella di controllo "Prefer 32 bit" è abilitata solo per i progetti eseguibili .NET 4.5+.

— Lee Grissom,

Un altro vantaggio di anycpu32bitspreferred è che un altro .exe in esecuzione a 64 bit può caricare tale assembly.

— Bruno Martinez,

Personalmente penso che sia orribile che lo impostano per impostazione predefinita senza l'impostazione Strumenti per disattivarlo. Ancora peggio, non puoi cercarlo poiché non nei file csproj a meno che non sia spento! Probabilmente aggiunto a causa delle incompatibilità di Office Automation con CPU Qualsiasi su un computer x64 con la maggior parte delle persone che installano Office a 32 bit.

— Dave,

@BrianDavidBerman esiste, se si imposta false su 32 ma si preferisce e si imposta x64 o Any CPU su un computer a 64 bit.

— Lex Li

La differenza tra x86 e Any CPU 32 bit preferita è che in quest'ultimo caso il flag largeaddressaware è impostato sull'eseguibile. Ciò significa che il processo a 32 bit in esecuzione su un sistema operativo a 64 bit può utilizzare 2 GB di memoria in modalità x86 e 4 GB di memoria in qualsiasi modalità preferita di CPU a 32 bit.

— Nic,

Ecco una semplice risposta:

Nota: AnyCPU-32bitPreferred è disponibile solo in .Net versione 4.5 e successive.

— Yousha Aleayoub
fonte

Qual è la differenza tra "funziona come 32 bit" rispetto a funziona come "WoW64". Ho pensato WoW64 = "Windows (32 bit) su Windows64" ed era necessario per l'esecuzione di qualsiasi applicazione a 32 bit.

— Peter Cordes,

C'è una fonte per questo? Apparentemente ovunque altro mi dice che l'impostazione predefinita è anycpu32bitpreferred, che è una grande differenza per le persone che eseguono macchine Windows a 64 bit (è molto).

— Ran Sagy,

@RanSagy puoi semplicemente testarlo creando un nuovo progetto e controllando Project -> Properties -> Build tab -> Platform target... ma nota che AnyCPU-32bitPreferredè disponibile solo in .Net versione 4.5 e successive. Ecco perché l'impostazione predefinita è AnyCPU.

— Yousha Aleayoub il

In alcuni casi il mio era oscurato; Speravo solo che ci fosse della documentazione su cosa succede in .net 4.5+ o .net standard / core (o davvero, MSBuild 16)

— Ran Sagy,

-1

Il motivo è: nel caso in cui non si desideri utilizzare più memoria con applicazioni a 64 bit. Ciò significa che se l'applicazione è AnyCPU , si desidera eseguire a 32 bit.

Per aggiungere altro, l'impostazione in Visual Studio ha come target il CLR specifico:

Visual Studio installa la versione a 32 bit del CLR su un computer x86 e sia la versione a 32 bit sia la versione a 64 bit appropriata del CLR su un computer Windows a 64 bit. (Poiché Visual Studio è un'applicazione a 32 bit, quando è installato su un sistema a 64 bit, funziona con WOW64.)

Fare riferimento all'articolo Applicazioni a 64 bit ( MSDN ).

— Perù
fonte

Non sono sicuro che sia esatto. Come intendo, i file eseguibili .NET, indipendentemente da 32 o 64, sono ancora limitati a circa 2 GB per processo.

— JP Richardson,

Modificato la mia risposta. Ma non è sicuro se questo è quello che stai cercando :)

— Perù,

@Aaron, il compilatore imposta essenzialmente il flag per il runtime per decidere se è corretto caricare assembly (ovvero bloccare l'assembly solo x86 da caricare nel processo x64) e come avviare il processo (per il nuovo EXE) in base ai flag. Credo che IL sia lo stesso per entrambi i gusti.

— Alexei Levenkov,

@JPRichardson Sì, hai ragione. Ma in .net 4.5 hai la possibilità di aumentare le dimensioni. fare riferimento a MSDN

— Perù il

@JPRichardson, né eseguibile a 32 né 64 bit .Net limitato a 2 GB per processo - innanzitutto lo spazio degli indirizzi per processo è la limitazione del livello del sistema operativo (2/3 + GB per il processo a 32 bit e molto altro per 64 bit), la seconda versione anche a 32 bit può utilizzare più di 2 GB se il flag "LargeAddressAware" è impostato sull'eseguibile. Le uniche restrizioni da 2 GB che conosco riguardano le dimensioni di array / allocazione che sono limitate dall'intervallo Int32 (circa 2 GB).

— Alexei Levenkov,