Il codice scritto in Vista 64 è compatibile con il sistema operativo a 32 bit?

Question

Stiamo ottenendo nuove macchine di sviluppo e stiamo passando a Vista 64 Ultimate per sfruttare la nostra RAM da 8 GB.Il nostro manager vuole che eseguiamo tutto lo sviluppo su macchine virtuali a 32 bit per assicurarci che non ci siano problemi con il passaggio del nostro codice alla produzione.

Esiste un modo per garantire che i programmi risultanti funzioneranno su sistemi operativi a 32 bit?Non mi dispiace usare le macchine virtuali, ma non mi piace il modo in cui ti costringono a tornare a una visualizzazione di tipo monitor "singolo".Mi piace spostare le barre degli strumenti VS sull'altro monitor.

MODIFICARE:Utilizziamo Visual Studio 2005 e 2008, VB.NET e/o C#

MODIFICARE:Utilizzando Harpreet risposta, questi sono i passaggi che ho utilizzato per impostare il mio IDE di Visual Studio per compilare x86/32bit:

1. Fare clic su Compila e aprire Gestione configurazione
2. Selezionare l'elenco a discesa Piattaforma di soluzioni attive
3. Seleziona x86 se è nell'elenco e vai al passaggio 5, altrimenti Seleziona <New...>
4. Nella finestra di dialogo Nuova piattaforma di soluzione, selezionare x86 e premere OK
5. Verifica che la piattaforma selezionata per tutti i tuoi progetti sia x86
6. Fare clic su Chiudi.

Godere.

Grazie, Keith

Answer 1

Faccio sviluppo su macchine a 64 bit per Windows a 32 bit.Non è un problema.Dovresti assicurarti che i tuoi progetti siano impostati per la compilazione in modalità x86 per essere conservativi.Ti consigliamo di esaminare ogni progetto nella soluzione e ricontrollarlo.Potresti anche utilizzare l'impostazione AnyCPU, ma è un po' più rischiosa poiché funzionerà in modo diverso sulla tua macchina di sviluppo rispetto a una macchina a 32 bit.Ovviamente vuoi evitare la modalità a 64 bit.

I problemi che ho riscontrato sono driver che non funzionano quando l'app è compilata per 64 bit (esplicitamente 64 bit o AnyCPU compilata e in esecuzione su Windows a 64 bit).Questi problemi sono completamente evitabili attenendosi alla compilazione x86.Ciò dovrebbe rivelare tutti i difetti sulle tue macchine di sviluppo.

Idealmente, potresti impostare un ambiente di creazione e test che possa essere eseguito frequentemente su una macchina a 32 bit.Ciò dovrebbe rassicurare il tuo management e consentirti di evitare la VM come desktop.

Answer 2

Finché compili i tuoi eseguibili a 32 bit, verranno eseguiti sia su macchine Windows a 32 bit che a 64 (garantito).L'utilizzo di macchine di sviluppo a 64 bit ha il vantaggio di poter iniziare a testare il codice con la compilazione a 64 bit (per verificare cose come i puntatori convertiti in numeri interi a 32 bit), in questo modo rendendo più semplice la transizione a 64 bit in futuro (se la tua azienda dovesse scegliere per fare una versione a 64 bit).

Answer 3

La compilazione per un sistema operativo a 64 bit è un'opzione nel compilatore.Puoi assolutamente compilare un file exe a 32 bit da Vista a 64 bit.Quando esegui l'app, puoi vedere nel TaskManager che c'è un "*32" accanto al processo...questo significa che è a 32 bit ;)

Credo che i tuoi manager abbiano bisogno di più istruzione su cosa significhi realmente il sistema operativo a 64 bit :)

Answer 4

Non una risposta alla tua domanda, ma forse una soluzione al tuo problema:VirtualBox (e probabilmente altri) supporta la modalità "integrazione perfetta", che ti offre solo una seconda barra di avvio e ti consente di trascinare liberamente le finestre.

Inoltre, e questa è una risposta alla tua domanda, dipende dalle impostazioni di compilazione.Puoi compilare per ambienti diversi e puoi compilare perfettamente programmi a 32 bit su un sistema a 64 bit con Visual Studio.Non posso dirti come, ma sono sicuro che qualche guru di Visual Studio potrebbe aiutarti.

Answer 5

Sviluppiamo un'applicazione a 32 bit utilizzando VS 2005 (presto 2008) e abbiamo appena acquistato alcune nuove macchine con XP Pro x64 o Vista Business a 64 bit in modo da poter sfruttare la RAM extra mentre teniamo un briefing sul possibilità di effettuare un porting a 64 bit se diventa commercialmente necessario farlo.Non abbiamo avuto alcun problema nel farlo, a parte la modifica di alcuni script nel nostro ambiente di sviluppo, ecc.

Gli sviluppatori che non sono stati inclusi in questo ciclo di aggiornamento utilizzano ancora macchine a 32 bit, quindi dovrebbero riscontrare problemi quando gli unit test e la suite di test dell'applicazione vengono eseguiti normalmente prima del check-in.

Ciò che facciamo è anche assicurarci di avere una serie di macchine "test build" composte da configurazioni "tipiche" (XP/Vista, 2/4/8 core, ecc.) che costruiscono e testano set di check-in - disponiamo di diverse suite di test per stabilità, prestazioni, ecc.- prima che siano inseriti nell'area di integrazione vera e propria.Ancora una volta, questi non hanno riscontrato alcun problema con l'esecuzione di un'applicazione a 32 bit costruita su un sistema operativo a 64 bit.

Ad ogni modo, come altri hanno già detto, non mi aspetto che sia un problema perché è il compilatore che genera il codice appropriato per il sistema operativo di destinazione indipendentemente dal sistema operativo su cui è effettivamente in esecuzione il compilatore.

Answer 6

sì, come stava dicendo Adam.Ci sono 3 opzioni:MSIL (predefinito), x64 e x86.Puoi scegliere come target x64 e genererà DLL specifiche per sistemi a 64 bit, oppure puoi eseguire x86 che verrà eseguito su 32 bit e 64 bit, ma avrà le stesse restrizioni di 32 bit su un sistema a 64 bit.

MSIL sostanzialmente consentirà al JITer di emettere l'istruzione specifica della piattaforma (con una leggera penalità in termini di prestazioni rispetto a un'immagine nativa)

MODIFICARE:nessuna lingua, quindi sto parlando di linguaggi .net framework come vb.net e c#, c++ è un animale completamente diverso.

Answer 7

Ho trovato questo oggi:

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

Sviluppo x64 con .NET

All'inizio di quest'anno sono passato a un sistema operativo a 64 bit: Vista Ultimate x64 per l'esattezza.Nella maggior parte dei casi, questo processo è stato relativamente indolore, ma si sono verificati alcuni intoppi lungo il percorso (principalmente driver compatibili con x64, ma non è questo il punto di questa discussione).

Nel mondo dello sviluppo x64, ci sono stati alcuni punti problematici che ho pensato di delineare qui.Questo elenco probabilmente crescerà, quindi aspettati post futuri sull'argomento.

Nel meraviglioso mondo dello sviluppo .NET, applicazioni e assiemi possono essere compilati per essere destinati a varie piattaforme.Per impostazione predefinita, le applicazioni e gli assembly vengono compilati come Qualsiasi CPU in Visual Studio.In questo scenario, CLR caricherà l'assembly come qualunque sia la destinazione predefinita per il computer su cui viene eseguito.Ad esempio, quando si esegue un eseguibile su una macchina x64, verrà eseguito come processo a 64 bit.

Visual Studio prevede inoltre 3 target di piattaforma specifici:x86, x64 e Itanium (IA-64).Quando si crea un eseguibile come destinazione specifica, verrà caricato come processo di quel tipo.Ad esempio, un eseguibile con destinazione x86 eseguito su un computer x64 verrà eseguito come processo a 32 bit utilizzando il livello CLR e WOW64 a 32 bit.Quando gli assembly vengono caricati in fase di esecuzione, possono essere caricati da un processo solo se la loro destinazione corrisponde a quella del processo di hosting o se è compilata come Qualsiasi CPU.Ad esempio, se x64 fosse impostato come destinazione per un assembly, potrà essere caricato solo da un processo x64.

Questo è entrato in gioco in alcuni scenari per me:

• XNA: XNA è disponibile solo come set di assembly a 32 bit.Pertanto, quando si fa riferimento agli assembly XNA, l'eseguibile/assembly che li utilizza deve essere destinato alla piattaforma x86.Se è destinato come x64 (o come Qualsiasi CPU ed eseguito su un computer a 64 bit), verrà generato un errore durante il tentativo di caricare gli assembly XNA.

• Microsoft Robotics Studio: XInputGamepadService utilizza XNA internamente per comunicare con il controller Xbox 360.Vedi sopra.

• DirectX gestito: sebbene sia già deprecato e sostituito con XNA, ha ancora i suoi usi.Gli assembly non sono contrassegnati per un target specifico, tuttavia ho avuto difficoltà con le eccezioni di memoria, soprattutto con l'assembly Microsoft.DirectX.AudioVideoPlayback.

• Phidgets: a seconda della libreria scaricata e di quando, potrebbe essere contrassegnata o meno solo come 32 bit.La versione corrente (8/11/07) è contrassegnata come tale e quindi richiede un processo a 32 bit per ospitarla.Il modo più semplice per determinare se un file eseguibile o un assembly è destinato a una piattaforma specifica consiste nell'utilizzare l'applicazione corflags.Per utilizzarlo, apri un prompt dei comandi di Visual Studio dal menu Start ed eseguilo sull'assembly che desideri controllare.

Il modo più semplice per determinare se un file eseguibile o un assembly è destinato a una piattaforma specifica consiste nell'utilizzare l'applicazione corflags.Per utilizzarlo, apri un prompt dei comandi di Visual Studio dal menu Start ed eseguilo sull'assembly che desideri controllare.