Je crois que le type d'architecture (x86 vs x64) est abstrait pour vous lors de la création de programmes .Net, mais y a-t-il d'autres considérations qui peuvent causer des problèmes?Y at-il des considérations à prendre en charge lors de l'exécution de votre programme .net sur x64 vs x86?
Méfiez-vous des bibliothèques COM tierces ou des bibliothèques tierces .NET qui effectuent secrètement des appels win32. C'est là que nous avons eu nos plus grands maux de tête.
x64 vous permettra d'adresser plus de mémoire, mais étant donné le même code, il utilisera plus de mémoire que x86.
De l'MSDN doco, entre autres considérations:
Dans de nombreux cas, les assemblées se dérouleront le même sur le 32 bits ou 64 bits CLR. Quelques raisons d'un programme à se comporter différemment lorsqu'il est exécuté par le 64 bits CLR comprennent:
Structs qui contiennent des membres qui changent de taille en fonction de la plate-forme, telles que tout type de pointeur.
Arithmétique de pointeur qui inclut tailles constantes.
Déclarations incorrectes d'appel de plate-forme ou COM qui utilisent Int32 pour les poignées au lieu de IntPtr.
casting IntPtr à Int32
En outre, l'emplacement des fichiers par défaut.
Cet article a beaucoup de bonnes questions à connaître: http://osnews.com/story/20330/Windows_x64_Watch_List
Personnellement, mon patron a un ordinateur Vista 64 bits, et je programme en mode 32 bits. Nous avons rencontré les questions suivantes:
Registre pour applications 32 bits qui est caché (en quelque sorte) dans un dossier Wow6432Node. Toutes les applications pour lesquelles vous avez l'habitude de trouver un chemin dans le registre ne seront pas dans ce nœud (SQL Server ne le sera pas, par exemple). SysWow64 dans le dossier C: \ Windows peut provoquer des problèmes de DLL n'étant pas là où ils sont nécessaires (nous avons eu ce problème avec un composant de licence tiers). Parfois les fichiers dont vous avez besoin se trouvent dans "C: \ Program Files (x86)" plutôt que "C: \ Program Files". Suce aussi.
Lecture et écriture à 64 valeurs de bits est pas thread-safe sur une plate-forme 32 bits. La lecture d'une valeur 64 bits prend deux opérations qui pourraient être interrompues par un changement de contexte. Voir l'article MSDN sur Threading.Interlocked.Read pour plus d'informations.
MSDN avait mis un peu de papier en ce qui concerne les questions de portage des applications 32 bits sur l'environnement d'exécution 64 bits.
http://msdn.microsoft.com/en-us/library/ms973190.aspx
Deux autres blogueurs avaient déjà écrit sur le développement 64 bits lorsqu'ils travaillaient dans l'équipe CLR
Dans mon expérience de portage d'une L'application Asp.NET était fondamentalement sans faille. Exécuter sur machine 32 bits et sur 64 bits et aucun problème ne survient, en plus d'avoir plus de mémoire disponible. Cela arrive parce que beaucoup de problèmes déjà mentionnés (registre, threading, etc.) ont été gérés par Asp.NET et que vous devez les corriger correctement pour qu'ils s'exécutent dans l'environnement Asp.NET. Côté client (forme Windows) la même chose s'est produite mais si vous avez utilisé des API "non sécurisées" pour obtenir des dossiers spéciaux ou un accès au registre, un problème peut survenir, comme déjà indiqué.
Cordialement Massimo