Portieren einer Windows-App auf Arm64: Der vollständige Weg

Ein nativer Arm64-Build macht den Unterschied zwischen Ihrer App, die mit voller Geschwindigkeit die Akkulaufzeit schont, und einer, die mühsam durch die Prism-Emulation kriecht. Er ermöglicht außerdem das, was Emulation gar nicht leisten kann: Kernel-Treiber, Shell-Erweiterungen und tiefe Hardware-Integration. Hier ist der vollständige Weg von reinem x64 zur Auslieferung eines nativen Arm64-Builds.

Schritt 1: Prüfen Sie zuerst Ihre Abhängigkeiten

Dieser Schritt entscheidet über Erfolg oder Misslingen des Ports und erfolgt, bevor Sie eine einzige Build-Einstellung ändern. Jede statische Bibliothek, jedes NuGet-Paket, jede native DLL und jedes Plugin, das Ihre App lädt, muss einen Arm64- (oder ARM64EC-) Build bereitstellen. Gehen Sie den gesamten Abhängigkeitsbaum durch. Eine einzige reine x64-Abhängigkeit, für die es keinen Arm64-Build und keinen Ersatz gibt, ist das Signal, dass Sie ARM64EC statt eines reinen Arm64-Ports benötigen. Schlagen Sie Ihre Abhängigkeiten in unserem Katalog nach, um zu sehen, welche bereits nativ ausgeliefert werden.

Schritt 2: Fügen Sie die ARM64-Lösungsplattform hinzu

In Visual Studio (verwenden Sie 2022 17.4+): Konfigurations-Manager → Aktive Lösungsplattform → <Neu...> → ARM64 auswählen, Einstellungen von Ihrer vorhandenen x64-Plattform kopieren, „Neue Projektplattformen erstellen” aktiviert lassen. Ihr Projekt hat jetzt ein Arm64-Ziel.

Schritt 3: Installieren Sie die Arm64-Build-Tools

Fügen Sie über den Visual Studio-Installer die Arm64-Build-Tools hinzu (MSVC Arm64-Compiler/-Bibliotheken). Sie benötigen kein Arm-Gerät zum Erstellen – Visual Studio cross-kompiliert von einem x64-Rechner aus für Arm64.

Schritt 4: Nativ erstellen oder cross-kompilieren

Zwei gültige Einrichtungen:

• Auf dem Gerät (nativ): Entwickeln auf einem Snapdragon X-Laptop – Sie erhalten lokales Debugging und können Ihre Testsuite auf dem Zielgerät ausführen.
• Cross-kompilieren (x64-Host): Schneller und günstiger, aber Sie können das Ergebnis nicht lokal ausführen – Sie richten Remote-Debugging auf einem Arm-Gerät oder einer VM ein.

Das pragmatische CI-Muster ist Cross-Kompilieren auf x64 plus einen nativen Arm64-Job für Tests; siehe den CI/CD-Leitfaden.

Schritt 5: Wenn eine Abhängigkeit blockiert → ARM64EC

Wenn eine wesentliche Abhängigkeit rein x64 ist und nicht ausgetauscht werden kann, müssen Sie nicht vollständig emuliert bleiben. ARM64EC ermöglicht nativem ARM64EC-Code und emuliertem x64-Code, einen Prozess gemeinsam zu nutzen – kompilieren Sie Ihre heißen Pfade nativ neu, während die hartnäckige x64-Abhängigkeit weiterläuft. Ausführliche Details im ARM64EC Deep Dive.

Schritt 6: Überprüfen und ausliefern

Bestätigen Sie, dass der Build wirklich nativ ist – die Spalte „Architektur” im Task-Manager sollte ARM64 anzeigen (siehe So überprüfen Sie es). Dann veröffentlichen: Sobald Ihr Arm64-Build auf winget, im Microsoft Store oder auf GitHub Releases landet, erkennen Kompatibilitäts-Tracker wie unserer dies und stufen Ihren Eintrag auf nativ um. Durchsuchen Sie den Katalog nativer Apps und den Trend nativer Apps, um das Ökosystem zu sehen, dem Sie beitreten.

Der Entscheidungsbaum

• Alle Abhängigkeiten haben Arm64-Builds → reines Arm64, bestes Ergebnis.
• Ein oder zwei reine x64-Abhängigkeiten, kein Ersatz → ARM64EC, inkrementell.
• Eine blockierende Kernel-Treiber-Abhängigkeit → das ist ein Treiber-Port, ein separater Aufwand.