Compilation croisée dans Visual Studio sous Windows : guide complet

Maîtriser la compilation croisée dans Visual Studio à partir de Windows n'est pas anodin : il existe des nuances entre architectures, OS, chaînes d'outils et linkers qui définissent ce qui est possible et ce qui ne l'est pas. Dans ce guide pratique et détaillé, nous avons rassemblé toutes les connaissances nécessaires à la configuration et à la compilation croisée avec Visual Studio, MSBuild et CMake, y compris des scénarios avec AOT natif, le développement mobile, les environnements multi-machines et le débogage à distance sous Linux.

L'idée est qu'avec une seule lecture, vous savez clairement ce que chaque technologie prend en charge, ce que Composants de Visual Studio vous devez installer, comment préparer les dépendances sur Linux, quels chemins et clés de registre sont nécessaires sur les serveurs de build sans VS, et comment déplacer le même code entre Windows et Linux à l'aide de l'intégration CMake et Visual Studio.

Qu'est-ce que la compilation croisée et quelles sont les véritables limites de l'AOT natif ?

La compilation croisée consiste à générer des binaires pour une plate-forme autre que celle sur laquelle le compilateur s'exécute, soit en changement de système d'exploitation ou d'architecturePar exemple, produire des exécutables Windows à partir de Linux ou cibler ARM64 à partir d'un hôte x64.

Dans le contexte de .NET avec AOT natif, le processus utilise éditeurs de liens et bibliothèques de plateformes Combiner du code managé compilé avec des dépendances natives (statiques ou dynamiques). Cela introduit une limitation importante : la disponibilité des liens croisés et des bibliothèques cibles détermine les couples système d'exploitation/architecture viables.

À ce jour, il n'existe aucun moyen standardisé et pris en charge d'obtenir le SDK natif macOS sous Windows/Linux, le SDK Windows sous Linux/macOS ou un SDK Linux sous Windows/macOS. Par conséquent, L'AOT natif ne prend pas en charge la compilation croisée entre les systèmes d'exploitationSi vous devez compiler entre différents systèmes d’exploitation, le moyen pratique est d’utiliser l’émulation, une machine virtuelle ou WSL sous Windows.

La compilation croisée entre architectures au sein d'un même système d'exploitation est un domaine d'amélioration possible. À condition d'installer la chaîne d'outils appropriée, c'est possible. compilation croisée entre x64 et ARM64 sous Windows, macOS ou Linux. Cette option est généralement utilisée pour produire des binaires ARM64 à partir d'un hôte de bureau x64.

Configuration requise et outils : Windows, macOS et Linux

Pour réussir la compilation croisée, vous devez installer le chaînes d'outils natives appropriées et ses utilitaires (linkers, objcopy/strip, runtime C, zlib, etc.). La disponibilité varie selon le système d'exploitation et la distribution.

Windows (x64 ↔ ARM64)La compilation croisée de Windows x64 vers Windows ARM64 (et vice versa) fonctionne en installant les outils de compilation C++ appropriés à partir de Visual Studio 2022. Si vous ciblez ARM64, assurez-vous d'inclure le composant Outils de build VS 2022 C++ ARM64/ARM64EC (derniers). Si vous ciblez x64, recherchez le composant Outils de création C++ x2022/x64 pour Visual Studio 86 (derniers).

macOSXcode est fourni par défaut avec les chaînes d'outils x64 et ARM64 ; vous pouvez donc cibler les deux architectures avec l'installation standard. Dans cet environnement, Visual Studio pour Mac et CMake s'appuie également sur ces Chaînes d'outils Apple.

LinuxChaque distribution gère les dépendances natives différemment. Au minimum, vous aurez besoin d'un éditeur de liens capable de générer des sorties vers la cible (par exemple, bruit), services publics objcopy/strip compatible avec la cible si vous activez StripSymbols, et les objets de la environnement d'exécution C et de zlib pour l'architecture cible.

Sur Ubuntu 22.04 amd64, les éléments suivants commandes peut être suffisant pour linux-arm64 (non documenté ou garanti par Ubuntu, mais fonctionne généralement) :

sudo dpkg --add-architecture arm64
sudo bash -c 'cat > /etc/apt/sources.list.d/arm64.list <<EOF
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy main restricted
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy-backports main restricted universe multiverse
EOF'
sudo sed -i -e 's/deb http/deb [arch=amd64] http/g' /etc/apt/sources.list
sudo sed -i -e 's/deb mirror/deb [arch=amd64] mirror/g' /etc/apt/sources.list
sudo apt update
sudo apt install -y clang llvm binutils-aarch64-linux-gnu gcc-aarch64-linux-gnu zlib1g-dev:arm64

Développement multiplateforme avec Visual Studio : mobile, jeux et UWP

Visual Studio ne se limite pas au bureau : il permet de créer applications pour Android, iOS et Windows Avec C#, .NET, C++ ou même HTML/JS, vous pouvez partager du code, des chaînes et des ressources entre projets, et même, dans certains cas, l'interface avec des frameworks comme Xamarin.Forms.

Si vous ciblez Android/iOS/Windows avec .NET, installez l'option « Développement pour mobiles avec .NET» (Xamarin). Vous bénéficierez de modèles de projet dédiés, d'un accès complet aux API natives et de la productivité de Visual Studio (concepteurs, IntelliSense, émulateurs et exécution sur appareils connectés). De plus, Xamarin.FormsXamarin.Forms vous permet de définir une interface utilisateur commune qui s'affiche nativement sur chaque plateforme.

Pour des jeux et des graphismes immersifs, Visual Studio propose Outils pour Unity (VSTU), intégrant l'édition et le débogage de scripts C#. La version actuelle inclut la prise en charge d'Unity 2019.4, la coloration ShaderLab, une synchronisation améliorée, un débogage plus complet et une génération de code optimisée pour MonoBehavior.

Si vous souhaitez cibler votre portefeuille d'appareils Windows 10 avec une seule application et un modèle d'interface adaptatif, vous pouvez créer une application UWPÀ partir des modèles UWP, Visual Studio facilite la conception visuelle, la prévisualisation de divers facteurs de forme et la sélection d'émulateurs et de simulateurs dans la barre d'outils.

Créer des environnements sans Visual Studio sur le serveur : multi-machine

Dans les entreprises, il est courant d'avoir besoin de serveurs de build sans licence Visual Studio complète. Il est possible de créer un environnement de build interne en installant Visual Studio sur un ordinateur hôte et copie de fichiers et de paramètres à l'équipe de développement. Cependant, cela ne vous donne pas le droit de redistribuer des logiciels en externe ni de proposer des environnements de développement à des tiers.

Notez également que la documentation a testé ces étapes sur des systèmes tels que Windows 8 (x86/x64), Windows 7 Ultimate et Windows Server 2008 R2 Standard. Une fois le processus terminé, vous pourrez compiler des applications de bureau C++ avec le SDK Windows 8 ou des applications VB/C# pour le .NET Framework 4.5, mais il existe des exceptions : cela ne fonctionne pas pour UWP ni pour .NET Framework ≤ 4.0 sans outils supplémentaires.

Prérequis. Avoir Visual Studio installé avec la charge de travail « Développement de bureau .NET » sur l'hôte. Sur la machine de build, installez au moins . NET Framework 4.5 (valide la clé de registre HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Version).

Copier le SDK et les outils Windows. À partir du chemin d'installation par défaut (%ProgramFiles%), il copie de manière récursive sur la machine de build, entre autres, les dossiers suivants : Windows Kits 8.0 (bin, Catalogs, DesignTime, include, Lib, Redist, References), Microsoft SDKs Windows v8.0A (NETFX 4.0 Tools), Common Files\Merge Modules et les répertoires clés de VC et MSBuild. Respectez les termes de licence de chaque kit installé, surtout si vous avez WDk/ADK.

De plus, il déplace des fichiers spécifiques tels que msobj110.dll, mspdb110.dll, mspdbcore.dll, mspdbsrv.exe, msvcdis110.dll, makehm.exe, VCVarsQueryRegistry.bat y vsvars32.batPour exécuter des binaires sur le serveur de build (par exemple des tests), copiez également le environnements d'exécution Visual C++ (msvcp110.dll, msvcr110.dll, atl110.dll, vcamp110.dll, etc.) vers System32/SysWOW64 selon l'architecture, et variantes de débogage de Debug_NonRedist (msvcp110d.dll, msvcr110d.dll, etc.).

Clés de registre requisesVous devez créer des entrées pour configurer les valeurs MSBuild. La racine dépend de l'architecture : sur x86, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft ; sur x64, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft (ci-après %RegistryRoot%). Créez les entrées de chaîne suivantes (REG_SZ), reflétant les valeurs disponibles sur l'hôte :

%RegistryRoot%\.NETFramework\v4.0.30319\AssemblyFoldersEx\VCMSBuild Public Assemblies@(Default)
%RegistryRoot%\Microsoft SDKs\Windows\v8.0@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86@InstallationFolder
%RegistryRoot%\VisualStudio\11.0@Source Directories
%RegistryRoot%\VisualStudio\11.0\Setup\VC@ProductDir
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkDir32
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkDir64
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkVer32
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkVer64
%RegistryRoot%\VisualStudio\SxS\[email protected]
%RegistryRoot%\VisualStudio\SxS\[email protected]
%RegistryRoot%\Windows Kits\Installed Roots@KitsRoot
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath10
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath11

Sur les ordinateurs x64, il ajoute également : %RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x64@InstallationFolderSi vous utilisez MSBuild 64 bits natif (ou TFS Build Service sur x64), ajoutez ces entrées à votre registre 64 bits natif : HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\Setup\VS@ProductDir et les trois valeurs de HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0 pour VCTargetsPath, VCTargetsPath10 et VCTargetsPath11.

Variables d'environnementLa manière directe est d'exécuter vcvarsall.bat dès …\VC\vcvarsall.batVous pouvez spécifier la chaîne d'outils cible comme argument ; si vous l'omettez, x86 est utilisé. Voici les arguments clés :

Argument	Type de compilateur	Hôte	Destination
x86	32 bits natifs	x86, x64	x86
x86_amd64	Passage à x64	x86, x64	x64
amd64	64 bits natifs	x64	x64

Si vous préférez, vous pouvez ajuster PATH manuellement en ajoutant les chemins vers Common7\IDE et les répertoires MSBuild 32/64 bits selon le cas, bien qu'en utilisant vcvarsall.bat Cela vous empêche d'oublier.

GAC pour les assemblages MSBuildMSBuild requiert des assemblys supplémentaires dans le GAC. Copiez-les depuis l'hôte vers n'importe quel dossier du serveur de build et enregistrez-les auprès de gacutil -i (vous le trouverez dans SDK Microsoft\Windows\v8.0A\bin\NETFX 4.0 Tools):

%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Build.CPPTasks.Common.v110.dll
%ProgramFiles%\Microsoft Visual Studio\<versión>\<edición>\Common7\IDE\CommonExtensions\Microsoft\VC\Project\Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll
%ProgramFiles%\Microsoft Visual Studio\<versión>\<edición>\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.VCProjectEngine.dll

Compilation. Sur la ligne de commande du serveur, vous pouvez appeler msbuild directement ou intégrer le processus dans Pipelines Azure, qui sélectionne automatiquement l'exécutable MSBuild correspondant à l'architecture de l'agent. Un exemple simple serait : msbuild solution.sln.

Si vous avez besoin d'un environnement de contrôle de source portable et versionné, vous pouvez créer un "Depot» copier les répertoires dans %Depot% et ajuster les fichiers MSBuild (Microsoft.CPP.Targets, etc.) pour référencer Fichier d'assemblage = »$(VCTargetsPath11)Microsoft.Build.CppTasks.Common.v110.dll» au lieu du GAC, en plus d'utiliser un Partenaire.AutoImports.props avec des propriétés telles que Chemin d'accès aux cibles VCTargets, chemin d'accès aux extensions MSBuild, répertoire d'installation VC y WindowsSdkDir, importé au début de chaque projet.

MSBuild, CMake et Pipelines : méthodes de build prises en charge

Visual Studio vous permet de compiler à partir de l'IDE, mais aussi avec MSBuild en CLI, Cfaire y Pipelines AzureChaque méthode offre des avantages :

• IDE:Builds instantanés, débogage intégré, compilation multithread et personnalisation des clés.
• Cfaire: Unifie le système de construction C++ entre Linux et Windows sans projets .vcxproj, idéal si votre base est déjà CMake.
• MSBuild (CLI):compile sans installer Visual Studio complet, permet des builds parallèles et une personnalisation étendue via des propriétés et des cibles.
• Pipelines Azure:Intégrez CI/CD, exécutez des tests automatisés et évoluez dans le cloud avec des tâches hautement personnalisables.

Dans l'IDE, vous pouvez ajuster les paramètres par plate-forme (Windows ou Linux) et par mode (Debug/Release), avec des options telles que répertoires de sortie, événements post-build, dépendances du projet, journaux et la suppression des avertissements. Cette flexibilité est essentielle pour gérer plusieurs architectures ou chaînes d'outils dans la même solution.

CMake Flow : création et débogage sous Windows et Linux depuis Visual Studio

Pour les builds C++ qui utilisent CMake, Visual Studio facilite l'ouverture du dossier repo (avec CMakeLists.txt), générer le cache automatiquement et configurer IntelliSense par cible. À partir de là, vous pouvez créer des configurations explicites (par exemple x64-Debug) qui sont conservées dans CMakeSettings.json.

Un flux typique commence par le clonage du projet, par exemple : git clone https://github.com/bulletphysics/bullet3.gitDepuis Visual Studio, ouvrez la racine CMakeLists et, après avoir généré le cache, vous verrez la « Vue des cibles CMake » avec les bibliothèques et les exécutables.

Pour déboguer sous Windows, sélectionnez l'exécutable cible (par exemple, AppBasicExampleGui.exe dans le SDK Bullet), définir un point d'arrêt dans une fonction clé (par exemple, mouseButtonCallback) et démarrez-le avec F5. Vous pouvez inspecter les variables, les objets, les threads et la mémoire grâce au débogueur intégré.

Pour Linux, ajoutez un paramètre «Linux-Debug» Dans CMakeSettings, sélectionnez le générateur « Unix Makefiles » si applicable et connectez-vous à la machine distante via SSH (Visual Studio gère ssh/rsync, gdb, make et CMake sur l'hôte Linux). Les outils habituels sont requis (build-essential, gdb, rsync, make, zip) et une version récente de CMake (au moins 3.8 ; Microsoft fournit des binaires universels que vous pouvez installer avec --prefix=/usr).

Si l'application est une application de bureau sous Linux, il peut être nécessaire de l'exporter DISPLAY. Obtenez la valeur avec echo $DISPLAY et ajoute launch.vs.json à partir de la configuration le préfixe correspondant dans pipeArgs: Par exemple, "export DISPLAY=:1;${debuggerCommand}" s'assurer que gdb commencer avec le bon contexte graphique.

Une fois le binaire exécuté sur la machine distante, Visual Studio le met au premier plan lorsque le point d'arrêt est atteint et affiche la pile d'appels (par exemple, des rappels comme CommonRigidBodyBase::mouseMoveCallback, X11OpenGLWindow::pumpMessage, etc.). De plus, vous verrez une console avec la sortie distante et vous pourrez envoyer une entrée standard si nécessaire.

Cette approche vous permet d'itérer dans un seul IDE sur Windows et Linux, tout en conservant Mêmes sources, chaînes d'outils différentes et une expérience de débogage cohérente.

Notes et considérations supplémentaires

Veuillez noter les limites officielles : l'AOT natif n'est pas pris en charge. multi-OS Sans virtualisation ni émulation, mais avec changement d'architecture (x64 ↔ ARM64) au sein du même système d'exploitation et avec la chaîne d'outils appropriée. Sous Linux, sachez que les utilitaires objcopy/strip que vous utilisez pour soutenir l'objectif si vous avez activé Symboles de bande.

Dans les scénarios de serveur, vérifiez le conditions de licence de chaque composant copié (kits Windows, WDK, ADK, etc.). Microsoft prévient que ces guides sont fournis « tels quels » et que les étapes ne sont pas forcément testées dans toutes les configurations possibles ; il est recommandé valider le pipeline dans votre environnement avant de le standardiser.

Enfin, lorsque vous configurez plusieurs plates-formes dans la même solution, nommez et séparez vos configurations et sorties (par exemple, différents dossiers par architecture/OS), automatisez avec MSBuild et, si vous le pouvez, intégrez tout en un seul pipeline CI/CD avec Azure Pipelines pour gagner en répétabilité et en traçabilité.

Avec les bonnes chaînes d'outils, une configuration MSBuild/CMake soignée et la prise en charge de l'IDE, il est possible de générer des binaires pour différentes architectures à partir de Windows, d'orchestrer des builds sur des serveurs sans VS et de déplacer le même code entre Windows et Linux avec une expérience de débogage cohérente. productif pour les équipes mixtes.