2010-04-07 8 views
2

Je souhaite que les applications .NET existantes (WinForms et WebForms) s'exécutent sur des machines 64 bits, optimisées pour tirer parti de plus de mémoire disponible sur les machines 64 bits. Que dois-je faire aux applications pour profiter de la mémoire? Est-ce que je sélectionne juste le CPU cible en 64 bits? Quel est l'avantage de sélectionner la cible par rapport à la compilation de l'application pour toutes les CPU et que le .NET optimise l'application localement?Application .NET et 64 bits

Est-ce que Crystal Reports (dans VS 2008) sera optimisé pour 64 bits et profitera de la mémoire haute?

+2

Qu'est-ce que votre application font qu'il a besoin de plus de 4 Go de mémoire? Une chose à considérer, Visual Studio (application assez complexe) est une application 32 bits. – R0MANARMY

+1

Vous pouvez entièrement séparer la deuxième question en une autre question. –

+0

@ R0MANARMY En fait, les applications .NET commenceront à manquer environ 2 Go de mémoire utilisée. J'ai moi-même rencontré cette limite avec une application de traitement d'enregistrements d'appels très complexe qui devait rapidement faire face à un énorme retard d'événements au démarrage. L'avantage de l'augmentation de la mémoire virtuelle a vraiment aidé là.Il est certainement concevable qu'un rapport complexe puisse avoir une très grande empreinte. – Josh

Répondre

7

Vous pouvez définir la CPU cible sur "AnyCPU". Ce sera JIT au code x86 sur les machines x86 et le code x64 sur les machines x64. Gardez à l'esprit que toute DLL non managée que vous référerez posera très probablement des problèmes. Je n'ai aucune idée si Crystal Reports prend des dépendances sur les DLL non managées (il s'agissait d'un wrapper fin sur la merde ActiveX, pas sûr maintenant.)

Si votre application fait uniquement référence au code managé qui est compilé pour AnyCPU, vous devriez être bien.

Il n'y a pas de véritable «avantage» à spécifier l'architecture de la CPU à l'avance. C'est une façon de faire face au fait que vous devrez peut-être faire en sorte que l'application ne fasse appel qu'à une architecture particulière. Par exemple, si vous utilisez le fournisseur OLEDB Microsoft Jet et que votre application est compilée pour AnyCPU, elle échouera à l'exécution sur un système d'exploitation x64 car elle s'exécutera en tant que processus x64 et aucun pilote OLEDB x64 pour Jet.

Dans ce cas, vous pourriez le forcer à cibler x86, puis même sur un système d'exploitation x64, l'application serait toujours à x86.

+0

+1 - beaucoup mieux que le mien –

+0

Je pensais que .Net Framework s'exécute en utilisant WOW sur les boîtes 64bit –

+0

@KNoodles, non il y a un framework x64. Si l'assembly d'entrée est compilé pour x86, l'ensemble fonctionnera évidemment dans WoW. Mais la valeur par défaut est de JIT à x64. Au moins c'était jusqu'à VS 2010 qui maintenant par défaut à x86 afin de cacher le fait que Intellitrace ne fonctionne pas en x64. Bleh. – Josh

0

Sauf si vous avez besoin d'une compilation conditionnelle pour pouvoir échanger des composants tiers qui requièrent un support natif sur différentes architectures, je recommande généralement de laisser le tout à l'exécution (Any CPU).

Le cadre de la machine cible s'en occupera et vous facilitera la vie plutôt que de devoir gérer la configuration de la construction pour divers environnements.

0

Il y a 2 saveurs d'exécution CR:

  • Crystal Reports (__gVirt_NP_NN_NNPS<__ exécution version complète)
  • Crystal Reports de base (bundles avec VS 2005, 2008)

Votre support 64 bits dépendra de la version que vous choisissez pour votre application.

Il n'existe aucune DLL 64 bits pour Crystal Reports XI Release 2 ou Crystal Reports 2008. Seuls les ensembles .NET 2005 (CR 10.2) et .NET 2008 (CR 10.5) (CR Basic) sont 64 bits. Si vous devez utiliser le runtime complet de Crystal Reports pour CR XI ou CR 2008, vous devez compiler votre application en mode 32 bits (x86).

SAP link 1

SAP link 2

Questions connexes