Portage d'une application Windows vers Arm64 : le chemin complet

Une compilation native Arm64 fait la différence entre une application qui économise la batterie à pleine vitesse et une qui peine à travers l’émulation Prism. Elle débloque également ce que l’émulation ne peut pas du tout faire : les pilotes noyau, les extensions shell, l’intégration matérielle profonde. Voici le chemin complet pour passer d’une application x64 uniquement à une version native Arm64.

Étape 1 : Auditez d’abord vos dépendances

C’est l’étape qui fait ou défait le portage, et elle intervient avant que vous ne touchiez à un seul paramètre de compilation. Chaque bibliothèque statique, package NuGet, DLL native et plugin chargé par votre application doit avoir une compilation Arm64 (ou ARM64EC). Parcourez l’arbre complet des dépendances. Une seule dépendance native x64 sans version Arm64 ni remplacement est le signal que vous aurez besoin d’ARM64EC plutôt que d’un portage pur Arm64. Recherchez vos dépendances dans notre catalogue pour voir lesquelles sont déjà natives.

Étape 2 : Ajoutez la plateforme de solution ARM64

Dans Visual Studio (utilisez la version 2022 17.4+) : Gestionnaire de configuration → Plateforme de solution active → <New...> → sélectionnez ARM64, copiez les paramètres de votre plateforme x64 existante, conservez l’option “Créer de nouvelles plateformes de projet” cochée. Votre projet a maintenant une cible Arm64.

Étape 3 : Installez les outils de compilation Arm64

Via l’installateur Visual Studio, ajoutez les outils de compilation Arm64 (compilateur/bibliothèques MSVC Arm64). Vous n’avez pas besoin d’un périphérique Arm pour compiler — Visual Studio effectue une compilation croisée vers Arm64 depuis une machine x64.

Étape 4 : Compilez nativement ou par compilation croisée

Deux configurations valides :

• Sur l’appareil (natif) : développez sur un ordinateur portable Snapdragon X — vous bénéficiez du débogage local et pouvez exécuter votre suite de tests sur la cible.
• Compilation croisée (hôte x64) : plus rapide et moins coûteux, mais vous ne pouvez pas exécuter le résultat localement — vous mettrez en place un débogage à distance vers un périphérique Arm ou une machine virtuelle.

Le modèle CI pragmatique est de compiler en croisé sur x64 + un travail natif Arm64 pour les tests ; voir le guide CI/CD.

Étape 5 : Quand une dépendance vous bloque → ARM64EC

Si une dépendance essentielle est uniquement x64 et ne peut pas être remplacée, vous n’êtes pas obligé de rester complètement émulé. ARM64EC permet au code natif ARM64EC et au code x64 émulé de partager un même processus — recompilez vos chemins critiques en natif pendant que la dépendance x64 récalcitrante continue de fonctionner. Tous les détails dans l’analyse approfondie d’ARM64EC.

Étape 6 : Vérifiez et publiez

Confirmez que la compilation est véritablement native — la colonne Architecture du Gestionnaire des tâches doit indiquer ARM64 (voir comment vérifier). Publiez ensuite : dès que votre compilation Arm64 arrive sur winget, le Microsoft Store ou GitHub Releases, les traceurs de compatibilité comme le nôtre la détectent et basculent votre entrée en natif. Parcourez le catalogue d’applications natives et la tendance de partage natif pour voir l’écosystème que vous rejoignez.

L’arbre de décision

• Toutes les dépendances ont des compilations Arm64 → Arm64 pur, meilleur résultat.
• Une ou deux dépendances x64 uniquement, sans remplacement → ARM64EC, incrémental.
• Une dépendance de pilote noyau bloquante → c’est un portage de pilote, un effort distinct.