2013-06-21 13 views
7

Attualmente sto usando CONTRO 2012 su un 64-bit PC, utilizzando Crystal Reports per VS 2012.Quale versione di Crystal Reports faccio riferimento (32 bit o 64 bit) durante lo sviluppo?

Dopo l'installazione di Crystal Reports per VS 2012, ho notato che ci sono 2 cartelle principali:

  • Comune \ SAP BusinessObjects Enterprise XI 4.0 \ win64_x64
  • Common \ SAP BusinessObjects Enterprise XI 4.0 \ win32_x86

L'applicazione che ho intenzione di distribuire può essere distribuito su entrambi i PC a 32-bit e 64-bit, in modo da quale Crystal Reports DL Ls dovrei fare riferimento? x86 o x64?

Oppure devo avere 2 soluzioni separate, una con le DLL x86 referenziate e l'altra con x64?

Aggiornamento:

Quello che ho fatto è stato quello di fare riferimento le DLL x86, quando in via di sviluppo, e installare la versione x86 ridistribuibile di Crystal Reports su tutte le mie macchine di distribuzione, a prescindere dalla sua architettura. Spero che ciò aiuti alcuni di voi ragazzi là fuori

+0

Avete intenzione di utilizzare un gestore di pacchetti come [InstallShield] (http://installshield.com) o [Chocolatey] (http://chocolatey.org/)? – craig

+0

Sì, sto utilizzando la versione rapida di InstallShield –

+0

Se si crea la versione a 64 bit dell'applicazione, viene creata automaticamente la versione a 32 bit? – craig

risposta

3

So che questa non è tecnicamente una risposta alla tua domanda, ma dal momento che rimane ancora senza risposta anche dopo aver impostato un premio, ho pensato che potrei suggerirlo comunque e hellip;

Potresti considerare nuovamente se hai davvero bisogno di una versione a 64 bit della tua applicazione. La maggior parte delle applicazioni line-of-business (che presumo sia ciò che stai creando, dal momento che stai generando report da esso) non traggono alcun beneficio dall'essere 64-bit.

È possibile creare e distribuire solo una versione a 32 bit (x86) e continuerà a funzionare su tutte le macchine, indipendentemente dal fatto che eseguano una versione di Windows a 32 o 64 bit. Questo perché tutte le versioni a 64 bit di Windows includono un sottosistema speciale() che esegue codice a 32 bit. È completamente trasparente e non ci sono praticamente problemi di compatibilità di cui parlare.

Un sacco di applicazioni vengono distribuite in questo modo. Visual Studio stesso è un eccellente esempio: è ancora codice a 32 bit, ma funziona bene anche su versioni a 64 bit di Windows, grazie a WOW64.

Per fare ciò, basta impostare il progetto su piattaforme x86 di destinazione e fare riferimento esclusivamente a DLL a 32 bit. Dato che creerai solo un singolo binario, ciò semplificherebbe enormemente gli sforzi di sviluppo e distribuzione, non solo in termini di individuazione delle DLL da referenziare, ma anche della quantità di codice che devi testare e del processo di distribuzione stesso.

Se si scrive un buon codice che segue gli idiomi standard e le pratiche raccomandate, l'aggiunta del supporto a 64 bit in un secondo momento (se mai si rivelerà un vantaggio per il proprio caso) sarebbe un'operazione abbastanza banale. .NET Framework astrae le differenze specifiche della piattaforma estremamente bene; è così che possono offrire un'opzione di targeting "Qualsiasi CPU".


A parte questo, se mi è permesso di speculare (perché non ho particolare esperienza con Crystal Reports), immagino che l'interfaccia pubblica è identico per entrambe le DLL a 32-bit e 64-bit.

In tal caso, è sufficiente fare riferimento alla versione a 32 bit per il lavoro di sviluppo, quindi configurare lo script di build per scegliere la versione corretta della DLL a seconda che si stia costruendo un 32 o 64- bit binario.

Naturalmente, il programma di installazione dovrebbe fare la stessa scelta, durante l'installazione (se si sta utilizzando un programma di installazione unificato) o quando si crea il programma di installazione stesso (se si dispone di programmi di installazione separati a 32 e 64 bit).

Problemi correlati