2009-02-11 6 views
6

Il mio team sta ottenendo nuove workstation XP64. Fino ad ora abbiamo utilizzato XP32. La maggior parte del nostro lavoro è gestita in C#/VS2008/.net 3.5 e SQL Server 2005. Tuttavia abbiamo un paio di app che sono ancora in VS2005/.net 2.0. La maggior parte delle nostre applicazioni sono app Webforms ASP.NET e servizi WCF in esecuzione su server a 64 bit in produzione. Tuttavia, abbiamo in corso alcuni sviluppi WPF che dovranno essere eseguiti su macchine a 32 bit.Il team sta passando da XP32 a XP64 per lo sviluppo di .NET - Qualsiasi trucchetto?

Ci sono trucchi o dolori di transizione di cui dovremmo essere a conoscenza?

+1

Perché XP64 non Vista64? Credo che Vista64 abbia driver migliori quindi XP64 –

+0

Il gruppo di infrastrutture vuole migrare da XP durante il ciclo di Windows 7. –

risposta

7

Se si fa riferimento a DLL di terze parti compilate per 32 bit, sarà necessario indirizzare le applicazioni per 32 bit. Questo può essere fatto cambiando le impostazioni del progetto o usando l'applicazione corflags con il parametro/32BIT +.

L'unico "trucco" che ho riscontrato nei miei molti mesi di XP x64 come workstation di sviluppo è che Edit-And-Continue non funziona nel debugger di Visual Studio in applicazioni a 64 bit.

0

Sun ha un buon articolo a riguardo. http://developers.sun.com/solaris/articles/ILP32toLP64Issues.html

Non è insolito per la corrente 32 bit applicazioni per scontato che il tipo int, tipo lungo, e puntatori sono le stesse dimensioni . Poiché la dimensione del long e il puntatore cambiano nel modello di dati LP64 , questa modifica da sola è la causa principale di principale dei problemi di conversione da ILP32 a LP64 .

+0

C# non gestisce direttamente i puntatori, si tratta di un problema non relativo al codice gestito. – joshperry

3

Dipende.

Hai usato P/Invoke nel tuo codice?

Avete utilizzato codice non gestito e dati di marshalling da e verso di esso? Se è così allora dovrai passare questo codice con un pettine a denti fini :(.

Tuttavia se il tuo codice è C# puro che non ha usato P/Invoke, l'unica differenza che dovresti vedere è un leggero aumento delle prestazioni e migliori prestazioni di memoria :).

È possibile tuttavia imbattersi in gremlins che trova i driver per le macchine di sviluppo.

Se si dispone di un codice a 32 bit, forse è possibile creare un'interfaccia WCF (le pipe denominate sono molto, molto veloci) e utilizzarlo per parlare con un servizio a 32 bit. So che non è possibile avere codice a 32 bit in un processo a 64 bit, ma penso che sia possibile aprire un pipe in un processo a 32 bit, a meno che non abbia sbagliato. In questo caso puoi sempre utilizzare TCP/IP. Potrebbe salvarti dal riscrivere il codice critico nel tuo sistema e permetterti di utilizzare WOW64 o una VM per affrontare un problema di migrazione.

+0

La stragrande maggioranza del nostro codice è puro C# gestito con l'eccezione di una win32 dll che è molto isolata e racchiusa in un servizio web. Sembra che dovremmo mantenere una macchina a 32 bit nel caso in cui abbiamo bisogno di cambiare quel servizio. La virtualizzazione funzionerebbe anche io sto indovinando. –

2

Ho usato XP 64 bit per alcuni mesi l'anno scorso. La mia esperienza è stata che lo stack di sviluppo Microsoft ha installato e funzionato senza problemi, inclusa una versione a 64 bit di SQL Server.

Ho riscontrato problemi con i driver di rete per la scheda di rete Marvell Yukon integrata della mia scheda Asus. I driver a 64 bit presentavano problemi gravi che non erano immediatamente evidenti, ma sono diventati evidenti dopo diversi mesi di intensi test. Le velocità di trasferimento di rete su una rete Gigabit non erano quelle previste e, quando due processi hanno avuto accesso alla stessa risorsa di rete, Windows si arresterebbe in modo anomalo.

La mia raccomandazione è, proprio come suggerito dall'altro poster, di testare l'installazione del software hardware prima di passare all'intero team. Questo è più probabile dove vedrai problemi.

3

speranza questo aiuto

Registering COM 32 bit DLL for asp 64 bit call

Many links about convention 32-64 bits

General FAQs About 64-bit Windows

64-bit System Design

vedere questo punte troppo Biggest performance improvement you’ve had with the smallest change? 01.238.007,316 mila

più

grandi punte del blog: Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR

Windows Application Quality Cookbook from Microsoft

DevReadiness.org
Questo sito è dedicato ad aiutare l'ecosistema di Windows ISV a sviluppare applicazioni di alta qualità per le nuove versioni della piattaforma. Windows 7 è stato annunciato di recente alla conferenza PDC 2008, a destra è disponibile il link "cookbook"

I ragazzi di Microsoft.com OPS hanno bloggato sulla loro migrazione a x64 e su come tutto funziona.
Running Microsoft.com on 64 Bit…The Dependencies, The Goodness, the Gotcha’s

2

Ho sviluppato su una piattaforma 64-bit per qualche tempo. Questo è un piccolo consiglio che può farti venire il mal di testa.

Se si ottiene l'eccezione

"BadImageFormatException" (ad esempio, "Could Non caricare o il montaggio 'Microsoft.TeamFoundation etc etc o una delle sue dipendenze. Un tentativo è stato fatto di caricare un programma con un formato errato ")

c'è un'alta probabilità che l'applicazione non sia in grado di trovare una versione a 64 bit dell'assieme.

Questo errore si verifica frequentemente durante l'accesso ai database utilizzando i driver OLEDB/Jet. Ho anche sperimentato questo con strumenti che si integrano con TFS.

Per risolvere questo problema, vai alla scheda "Compila" sotto le impostazioni del progetto, "Opzioni di compilazione avanzate" e seleziona "x86" come CPU di destinazione.

Spero che questo aiuti!

+0

Questo passaggio non ti riporta indietro al codice WOW a 32 bit? – Spence

+0

Sì, ma in realtà non hai scelta se hai bisogno della tua app per utilizzare i driver Jet. – Adrian

1
  • debug in modalità mista è un problema se si utilizza qualsiasi C++ e C# con le applicazioni a 64 bit.
  • Esistono ancora molti strumenti di sviluppo che non supportano l'esecuzione su Windows x64 o che non supportano il funzionamento con file binari a 64 bit. Prendiamo ad esempio Compuware DevPartner. Attualmente supporta solo lo sviluppo di applicazioni a 32 bit, ma l'applicazione verrà eseguita su Windows a 64 bit.
3

Non sarà possibile parlare con i database MS Access da .NET x64, perché non ci sono driver Jet x64.

Considererei questo un ottimo motivo per passare a x64.

+1

+1 per snarkyness generale (ed è stato divertente) :) – JMarsch

1

TFS non supporta i 64 bit (TFS server, non è sicuro per la squadra di explorer)

+0

Il client funziona correttamente: è solo il componente lato server del livello applicazione che non supporta 64 bit. – JMarsch

1

È possibile eseguire-in di un problema con string.GetHashCode() ritornano un valore diverso per la stessa stringa a 32 bit e macchine a 64 bit poiché eseguiranno versioni diverse del CLR.

Fondamentalmente:

“Il comportamento di GetHashCode dipende dalla sua attuazione, che potrebbe passare da una versione del Common Language Runtime ad un altro. Un motivo per cui questo potrebbe accadere è quello di migliorare le prestazioni del GetHashCode.”

Maggiori informazioni here e here.

1

Ci saranno due serie di origini dati ODBC (DSN) ora: 32-bit e 64-bit. Alcuni database non dispongono attualmente di driver aggiornati per 64 bit, quindi sarai costretto a utilizzare i driver a 32 bit o puoi semplicemente aspettare.

1

ci siamo imbattuti in 2 diversi tipi di problemi:

  1. Abbiamo avuto una componente di terze parti che wrappered un nativo a 32 bit dll. Il fornitore non offriva una versione a 64 bit, quindi abbiamo dovuto indirizzare lo sviluppo a 32 bit.

  2. Alcuni problemi di driver. XP-64 non l'ha preso su un intero lotto (ce l'ha ora?) Quando l'abbiamo provato. I problemi non erano legati allo sviluppo, ma abbiamo avuto qualche problema con i driver di stampa, i driver di rete, ecc. In vista, hanno cambiato il modello di driver, quindi ora potrebbero esserci più driver a 64 bit, ma non so se saranno retrocompatibili con XP.