Faut-il prendre en compte l’exécution de votre programme .net sur x64 vs x86?

Question

Je crois que le type d’architecture (x86 vs x64) a été résumé pour vous lors de la création de programmes .Net, mais existe-t-il d’autres facteurs pouvant causer des problèmes?

Answer 1

Faites attention aux bibliothèques COM tierces ou aux bibliothèques .NET tierces qui effectuent des appels Win32 en secret. C’est là que nous avons eu nos plus gros maux de tête.

Answer 2

Extrait du document MSDN , entre autres:

  

Dans de nombreux cas, les assemblys fonctionnent de la même manière sur le CLR 32 bits ou 64 bits. Voici quelques raisons pour lesquelles un programme se comporte différemment lorsqu'il est exécuté par le CLR 64 bits:

     

  

• Structures contenant des membres qui   changer de taille en fonction de la plate-forme,   comme tout type de pointeur.

  

• Arithmétique de pointeur qui inclut   tailles constantes.

  

• Invocation de plate-forme ou COM incorrecte   déclarations qui utilisent Int32 pour   poignées au lieu de IntPtr.

  

• Transtypage IntPtr en Int32

  

Aussi, les emplacements de fichier par défaut.

Answer 3

Cet article présente de nombreux problèmes intéressants à connaître: http://osnews.com/story/20330/Windows_x64_Watch_List

Personnellement, mon patron dispose d’un ordinateur Vista 64 bits et je programme en mode 32 bits. Nous avons rencontré les problèmes suivants:

• Le registre des applications 32 bits est caché (en quelque sorte) dans un dossier Wow6432Node. Toutes les applications pour lesquelles vous êtes habitué à trouver un chemin dans le registre ne se trouveront pas dans ce nœud (ce que SQL Server ne fera pas, par exemple).

• SysWow64 dans le dossier C: \ Windows peut entraîner des problèmes de DLL qui ne sont pas 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 dans "C: \ Program Files". Suce aussi.

Answer 4

• La lecture et l'écriture sur des valeurs 64 bits ne sont pas thread-safe sur une plate-forme 32 bits. La lecture d'une valeur de 64 bits nécessite deux opérations qui pourraient être interrompues par un changement de contexte. Voir l'article MSDN sur Threading.Interlocked.Read pour plus d'informations.

• Acceptez également entièrement les torial de répond ! : -)

Answer 5

MSDN a publié un petit article sur le transfert d’applications 32 bits vers un environnement d’exécution 64 bits.

http://msdn.microsoft.com/en-us/library /ms973190.aspx

Deux autres blogueurs avaient précédemment écrit sur le développement 64 bits lorsqu'ils travaillaient dans l'équipe CLR

• Gaurav Seth
• SpankyJ

Answer 6

x64 vous permettra d’adresser plus de mémoire, mais avec le même code, il utilisera plus de mémoire que x86.

Answer 7

D'après mon expérience, le portage d'une application Asp.NET était fondamentalement sans faille. S'exécute sur des machines 32 bits et 64 bits et aucun problème ne survient, à part le fait d'avoir plus de mémoire disponible. Cela est dû au fait que de nombreux problèmes déjà mentionnés (registre, threads, etc.) ont été gérés par Asp.NET et que vous devez les résoudre correctement pour qu'ils s'exécutent dans l'environnement Asp.NET.

Côté client (formulaire Windows), la même chose s’est produite, sauf si vous avez utilisé des "unsafe" " Les API permettant d’obtenir des dossiers spéciaux ou l’accès au registre peuvent donner lieu à des problèmes, comme indiqué précédemment.

Cordialement Massimo