Quels sont les changements que je dois faire ma demande de WCF pour fonctionner sur OS 64 bits?

Question

J'ai un C # / application WCF (hébergé dans les fenêtres de service) qui a été déployé et testé sur 32 bits serveur Windows. Maintenant, je dois déployer pour la production. Mon équipe réseau a suggéré de le déployer sur 64 bits de Windows Server pour tirer le meilleur parti des capacités de serveur.

Mes questions:

• Y at-il gain de performance dans le déploiement d'une application sur OS 64 bits? Si oui, combien?
• Est-ce que je dois faire tout spécial pour faire mon application 64 bits OS compatible? Si oui, quoi?

P.S. Mon application est compilée avec l'option "Tout CPU" (Est-il important?).

Answer 1

Il y a des blogs d'informations là-bas sur ce point. Un Bing rapide évoquera 1000s des points de discussion: http://www.bing.com/search?q=x64+vs+x86+server&src=IE-SearchBox&FORM=IE8SRC Mais, pour être bref:

Y at-il gain de performance sur le déploiement d'une application sur OS 64 bits? Si oui, combien?

L'avantage le plus notable est l'utilisation de la mémoire - Plus précisément, votre service / application, et tous les autres services / applications du serveur, ont plus d'espace pour jouer. Vrai que si vous avez 4 Go de RAM ou plus. Si vous avez moins que cela, vous perdez effectivement la mémoire par chaque attribution du bloc.

L'avantage, au niveau des performances brutes, est pour chaque cycle de CPU, vous peut exécuter jusqu'à 64bits d'information, au lieu de 32bits - deux fois plus d'informations. Beaucoup plus notable avec des applications multi-thread: par exemple Votre service WCF hébergé dans IIS, qui est multi-thread pour les requêtes entrantes. :)

Est-ce que je dois faire tout spécial pour faire mon application 64 bits OS compatible? Si oui, quoi?

Réponse courte, rien que-si-jamais. :) Et c'est l'avantage de .NET, lorsque vous compilez avec l'option par défaut "Any CPU"!

Lorsque vous compilez le code dans des ensembles, vous compilez code dans un langage intermédiaire (IL) - pas de code de la machine réelle. La version CLR .NET (Common Language Runtime), qui est installé sur le serveur spécifique / poste de travail / périphérique que vous déployez, est ce que prend votre code IL et il exécute dans les instructions natives pour cette plate-forme spécifique - x86, x64 ou IA-64 (ou AMD64, ARM, etc, s'il des réglages utilisés). Vous ne devez rien faire!

En ce qui concerne les pratiques de codage, il n'y a rien de particulier à faire non plus.

Référencez 3ème partie Assemblées autochtones? Maintenant, la seule préoccupation est que si vous utilisez le référencement des assemblées 3 parties par COM ou similaire qui sont compilés en code natif (à savoir essentiellement, assemblées 3ème partie dans les langues premières writting). Cela devient difficile de référencement d'un ensemble natif 32 bits via un CLR sur une machine x64 (en gros, vous devez forcer votre application à complile à 32 bits pour y accéder). Il y a d'autres contournements mais, ce qui est en dehors de la portée de cette réponse.

Voilà pourquoi je soit: coller à toutes les références .NET, référence seulement assemblées 3ème partie par écrit dans .NET, il suffit d'écrire moi-même ou supplient l'auteur du composant 3ème partie à libérer les deux versions compilées 32bits et 64bits. Ce dernier devient difficile à tester sur votre machine x86 (32 bits) que vous ne pouvez référencer les versions 32bits, mais vous devrez déployer les versions 64 bits.

Plus-of-a-mal de tête est en matière de votre propre projet WCF et les assemblées indigènes 3e partie, est que le haut-WCF service d'hébergement dans Visual Studio (ainsi que Cassini) est seulement 32 bits , ainsi que l'IntelliSense de Visual studio. Oui, il est amusant lors de l'utilisation des ensembles natifs 3e parti et essayer d'applications de débogage sur une machine x64. De bons moments!