2010-12-26 6 views
5

Attualmente sono in una situazione in cui ho macchine di sviluppo sia a 32 bit che a 64 bit che funzionano sul mio progetto C#. Devo fare riferimento a un paio dll che hanno sia una versione a 32 bit che a 64 bit. Ovviamente, le macchine a 32 bit devono fare riferimento alla DLL a 32 bit e le macchine a 64 bit alla DLL a 64 bit. Il problema che sto avendo è che ogni volta che uno sviluppatore controlla un codice, controlla anche i riferimenti alle DLL, quindi quando qualcuno dall'altra parte tira fuori il codice, non lo costruisce e devono aggiornare manualmente i loro riferimenti indietro a quello che dovrebbero essere. Quindi effettuano il check-in e gli altri sviluppatori devono correggere manualmente i loro riferimenti, ecc. Ecc. Alla nausea.Sviluppando su entrambi i processori a 32 bit e 64 bit, come dovrei strutturare il mio progetto per fare automaticamente riferimento alle dll corrette?

Non immagino che questo sia un nuovo problema, ma è la prima volta che ci ho provato. Esiste una pratica comune per fare in modo che un progetto faccia automaticamente riferimento alla dll corretta per la CPU? O forse un modo per avere un progetto a 32 bit e 64 bit, ognuno con i riferimenti corretti, e un modo (possibilmente uno strumento a linea di comando o un esterno che può essere legato a una build) per legarli insieme in modo che quando i nuovi elementi siano aggiunto o rimosso a uno, l'altro sarà anche aggiornato?

L'altra opzione è che ogni sviluppatore utilizzi lo stesso ambiente di sviluppo virtualizzato. Se seguo questa strada, posso virtualizzare un sistema a 64 bit su hardware a 32 bit, o devo andare dall'altra parte, e virtualizzare a 32 bit. Questo sarà un prodotto SaaS, quindi devo solo distribuire per un processore, e preferirei che sia 64 bit.

+0

Sembra che tu abbia bisogno di diversi file di progetto per i diversi obiettivi –

+0

@David Heffernan Lo penso anch'io, ma il mio nuovo problema è come impedire ai miei sviluppatori di dover aggiornare manualmente gli elementi del codice del progetto quando estraggono dal controllo del codice sorgente ? –

+0

@Matthew Vines che ne dite di un diverso tack, perché le DLL a cui si fa riferimento devono avere nomi diversi? Se sei gestito al 100% non puoi rendere tutto target AnyCPU? –

risposta

6

Qui trova un esempio per come modificare il riferimento di assemblaggio secondo la vostra piattaforma di destinazione:

http://www.ryangerard.net/post/8768828095/how-to-change-visual-studio-assembly-references

(dovete cambiare i file csproj manualmente). E per non dimenticare, sulle macchine a 32 bit scegliere 'x86' come piattaforma di destinazione, mentre sulle macchine a 64 bit, scegliere 'x64').

+1

Grazie per il collegamento. Questo è esattamente il problema che sto avendo, ed esattamente quello che sto cercando. Lunedì darò uno scatto e ti farò sapere come funziona per noi. –

2

Ho un problema simile ma la mia soluzione è leggermente diversa. Ho semplicemente sviluppato tutti gli sviluppatori con le DLL x86.

Quindi, il codice è in realtà identico su tutte le macchine. Quindi, in fase di esecuzione (e per i test), utilizzo un'app di avvio che testerà il sistema operativo e si muoverà attorno alle DLL in modo che in fase di esecuzione vengano utilizzate le DLL appropriate. La logica nel launcher è abbastanza semplice. Qualcosa di simile:

If IntPtr.Size = 8 Then 
    '-- Copy x64 DLLs into position 
Else 
    '-- Copy x86 DLLs into position 
End If 

Naturalmente, durante la copia, è necessario copiare indietro in modo da poter sempre passare tra x64 e x86 (nel caso di un'applicazione portatile). Tuttavia, se si sta installando un'applicazione non portatile, non è necessario il launcher poiché questo controllo del sistema operativo può essere eseguito all'interno del programma di installazione (quindi vengono installate solo le DLL appropriate).

Sarà necessario modificare il file di progetto per utilizzare una versione non specifica delle DLL in questione (altrimenti questo spostamento intorno alla logica non farà ciò che si desidera).

1

Sto attraversando un compito simile. La mia soluzione era usare gli eventi pre-buld e le cartelle di risorse specifiche. Le mie DLL di riferimento a 32 bit sono state inserite in una cartella e quelle a 64 bit in un'altra.

del "$ (ProjectDir) \ dlls *.dll" - eliminare tutte le DLL dalla cartella risorsa comune

xcopy "$ (ProjectDir) \ CommonResources" "$ (ProjectDir) \ DLL"/ s/i/y - Copia DLL comuni nella cartella delle risorse

I seguenti due comandi copiano le DLL corrette a 32 o 64 bit nella cartella delle risorse

se $ (PlatformName) == x64 (xcopy "$ (ProjectDir) \ dlls-64 \ My64Bit.dll" $ (ProjectDir) \ dlls/s/i/y)

se $ (PlatformName) == x 86 (xcopy "$ (ProjectDir) \ DLL-32 \ My32Bit.dll" $ (ProjectDir) \ dll/s/i/y)

Utilizzando comandi simili per la generazione del post, ho i riferimenti necessari alla directory di output per il packaging.

Problemi correlati