2013-06-21 18 views
7

Ich bin derzeit mit VS 2012 auf einem 64-Bit-PC, VS für Crystal Reports unter Verwendung von 2012Auf welche Version von Crystal Reports kann ich bei der Entwicklung verweisen (32-Bit oder 64-Bit)?

Nach der Installation von Crystal Reports für VS 2012, ich bemerkte, dass es zwei Hauptordner sind:

  • Gemeinsame \ SAP Businessobjects Enterprise XI 4.0 \ win64_x64
  • Common \ SAP Businessobjects Enterprise XI 4.0 \ win32_x86

Die App, die ich einsetzen werde können 32-Bit und 64-Bit-PCs auf beiden eingesetzt werden, so welche Crystal Reports DL Ls sollte ich referenzieren? x86 oder x64?

Oder brauche ich 2 separate Lösungen, eine mit den x86 Dlls referenziert, und die andere mit x64?

Update:

Was ich tat, war den x86-DLLs zu verweisen, wenn die Entwicklung, und installieren Sie die x86 verteilbar Version von Crystal Reports auf all meinen Einsatz Maschinen, unabhängig von ihrer Architektur. Hoffe das hilft euch Jungs da draußen

+0

Planen Sie einen Paketmanager wie [InstallShield] (http://installshield.com) oder [Chocolatey] (http://chocolatey.org/) zu verwenden? – craig

+0

Ja, ich verwende die Express-Version von InstallShield –

+0

Wenn Sie die 64-Bit-Version Ihrer Anwendung erstellen, erstellt sie automatisch die 32-Bit-Version? – craig

Antwort

3

Ich weiß, das ist technisch keine Antwort auf deine Frage, aber da es immer noch unbeantwortet bleibt, auch nachdem ich ein Bounty gesetzt habe, dachte ich, ich könnte es trotzdem vorschlagen & hellip;

Sie können erneut prüfen, ob Sie wirklich eine 64-Bit-Version Ihrer Anwendung benötigen. Die meisten Branchenanwendungen (von denen ich annehmen kann, dass Sie sie erstellen, da Sie Berichte daraus generieren) profitieren nicht wirklich davon, 64-Bit zu sein.

Sie können nur eine 32-Bit-Version (x86) erstellen und verteilen und sie wird weiterhin unter alle-Computer ausgeführt, unabhängig davon, ob sie eine 32-Bit- oder 64-Bit-Version von Windows ausführen. Dies liegt daran, dass alle 64-Bit-Versionen von Windows ein spezielles Subsystem (Windows-on-Windows, or WOW64) enthalten, das 32-Bit-Code ausführt. Es ist völlig nahtlos und es gibt praktisch keine Kompatibilitätsprobleme, von denen man sprechen kann.

Viele Anwendungen werden auf diese Weise bereitgestellt. Visual Studio selbst ist ein hervorragendes Beispiel: Es ist immer noch 32-Bit-Code, aber läuft auch auf 64-Bit-Versionen von Windows, dank WOW64.

Um dies zu tun, setzen Sie Ihr Projekt nur auf x86-Plattformen und verweisen ausschließlich auf 32-Bit-DLLs. Da Sie nur eine einzelne Binärdatei erstellen, würde dies die Entwicklungs- und Verteilungsbemühungen erheblich vereinfachen, nicht nur im Hinblick darauf, welche DLLs zu referenzieren sind, sondern auch die Menge an Code, die Sie testen müssen, und den Verteilungsprozess selbst.

Wenn Sie guten Code schreiben, der Standard-Idiomen und empfohlenen Vorgehensweisen folgt, wäre das Hinzufügen von 64-Bit-Unterstützung später (wenn es sich für Ihren Fall als nützlich erweist) eine ziemlich triviale Operation. Das .NET Framework abstrahiert plattformspezifische Unterschiede sehr gut. So können sie die Targeting-Option "Beliebige CPU" anbieten.


Abgesehen davon, wenn ich spekulieren, ich darf (weil ich keine besondere Erfahrung mit Crystal Reports haben), stelle ich mir vor, dass die öffentliche Schnittstelle sowohl für die 32-Bit- und 64-Bit-DLLs identisch ist.

In diesem Fall können Sie für Ihre Entwicklungsarbeit nur auf die 32-Bit-Version verweisen und dann Ihr Buildskript konfigurieren, um die richtige Version der DLL auszuwählen, je nachdem, ob Sie eine 32-Bit- oder 64-Bit-Version erstellen. Bit binär.

Natürlich muss das Installationsprogramm die gleiche Wahl treffen, entweder während der Installation (wenn Sie ein einheitliches Installationsprogramm verwenden) oder wenn Sie das Installationsprogramm selbst erstellen (wenn Sie separate 32-Bit- und 64-Bit-Installationsprogramme haben)).