Cross compilation en Visual Studio desde Windows: guía total

Dominar la compilación cruzada en Visual Studio desde Windows no es trivial: hay matices entre arquitecturas, sistemas operativos, toolchains y enlazadores que marcan lo que sí se puede hacer y lo que no. En esta guía práctica y detallada reunimos todo el conocimiento relevante para configurar y compilar de forma cruzada con Visual Studio, MSBuild y CMake, incluyendo escenarios con AOT nativo, desarrollo móvil, entornos multi-equipo y depuración remota sobre Linux.

La idea es que, con una sola lectura, tengas claro qué soporta cada tecnología, qué componentes de Visual Studio debes instalar, cómo preparar dependencias en Linux, qué rutas y claves de Registro son necesarias en servidores de compilación sin VS, y cómo mover el mismo código entre Windows y Linux usando CMake y la integración de Visual Studio.

Qué es la compilación cruzada y límites reales con AOT nativo

La compilación cruzada (cross compilation) consiste en generar binarios para una plataforma distinta de la que ejecuta el compilador, ya sea por cambio de sistema operativo o de arquitectura. Por ejemplo, producir ejecutables de Windows desde Linux o apuntar a ARM64 desde un host x64.

En el contexto de .NET con AOT nativo, el proceso usa enlazadores y bibliotecas de plataforma para combinar el código administrado compilado con las dependencias nativas (estáticas o dinámicas). Esto introduce una limitación importante: la disponibilidad de enlazadores cruzados y librerías destino determina qué pares de SO/arquitectura son viables.

A día de hoy no existe una forma estandarizada y soportada para obtener el SDK nativo de macOS en Windows/Linux, el Windows SDK en Linux/macOS o un SDK de Linux en Windows/macOS. Por eso, AOT nativo no admite compilación cruzada entre sistemas operativos. Si necesitas compilar entre SO distintos, la vía práctica es usar emulación, una máquina virtual o WSL en Windows.

Donde sí hay margen es en la compilación cruzada entre arquitecturas dentro del mismo SO. Siempre que instales la cadena de herramientas adecuada, es posible cross-compilar entre x64 y ARM64 en Windows, macOS o Linux. Este es el caso más habitual cuando se desea producir binarios ARM64 desde un host de escritorio x64.

Requisitos y herramientas por sistema: Windows, macOS y Linux

Para tener éxito con la compilación cruzada, necesitas instalar las toolchains nativas apropiadas y sus utilidades (enlazadores, objcopy/strip, runtime de C, zlib, etc.). La disponibilidad varía por sistema operativo y distro.

Windows (x64 ↔ ARM64). La compilación cruzada desde Windows x64 a Windows ARM64 (y viceversa) funciona instalando las «C++ Build Tools» correctas de Visual Studio 2022. Si tu objetivo es ARM64, asegúrate de incluir el componente «VS 2022 C++ ARM64/ARM64EC build tools (Latest)». Si apuntas a x64, busca el componente «Visual Studio 2022 C++ x64/x86 build tools (Latest)».

macOS. Xcode incorpora de forma predeterminada las cadenas de herramientas para x64 y ARM64, de modo que puedes orientar ambas arquitecturas con la instalación estándar. En este entorno, Visual Studio para Mac y CMake también se apoyan en dichas toolchains de Apple.

Linux. Cada distribución gestiona las dependencias nativas de forma distinta. Como mínimo, vas a necesitar: un enlazador capaz de emitir para el destino (por ejemplo, clang), utilidades objcopy/strip compatibles con el target si habilitas StripSymbols, y los objetos del runtime de C y de zlib para la arquitectura objetivo.

En Ubuntu 22.04 amd64, los siguientes comandos pueden ser suficientes para linux-arm64 (no está documentado ni garantizado por Ubuntu, pero suele funcionar):

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

Desarrollo multiplataforma con Visual Studio: móviles, juegos y UWP

Visual Studio no se limita al escritorio: permite crear apps para Android, iOS y Windows con C#, .NET, C++ o incluso HTML/JS. Puedes compartir código, cadenas y recursos entre proyectos, y en algunos casos hasta la interfaz con frameworks como Xamarin.Forms.

Si apuntas a Android/iOS/Windows con .NET, instala la opción «Desarrollo para dispositivos móviles con .NET» (Xamarin). Obtendrás plantillas de proyecto específicas, acceso completo a las APIs nativas y la productividad de Visual Studio (diseñadores, IntelliSense, emuladores y ejecución en dispositivos anclados a red). Además, Xamarin.Forms permite definir una UI común que se renderiza nativamente en cada plataforma.

Para juegos y gráficos inmersivos, Visual Studio ofrece Tools for Unity (VSTU), integrando edición y depuración de scripts C#. La versión actual aporta compatibilidad con Unity 2019.4, coloreado de ShaderLab, mejor sincronización, depuración más completa y generación de código mejorada para MonoBehavior.

Si quieres orientar la gama de dispositivos Windows 10 con una sola app y un modelo de interfaz adaptable, puedes crear una aplicación UWP. Empezando con plantillas UWP, Visual Studio facilita el diseño visual, previsualizaciones para varios factores de forma y selección de emuladores y simuladores desde la barra de herramientas.

Entornos de compilación sin Visual Studio en el servidor: multi-equipo

En empresas es habitual necesitar servidores de build sin licencias completas de Visual Studio. Es posible crear un entorno de compilación interno instalando Visual Studio en un equipo host y copiando archivos y configuraciones al equipo de compilación. Eso sí: no te confiere derechos para redistribuir software externamente ni ofrecer entornos de compilación a terceros.

Considera también que la documentación probó estos pasos en sistemas como Windows 8 (x86/x64), Windows 7 Ultimate y Windows Server 2008 R2 Standard. Tras completar el proceso, podrás compilar apps de escritorio C++ con Windows 8 SDK o de VB/C# para .NET Framework 4.5, pero hay excepciones: no sirve para UWP ni para .NET Framework ≤ 4.0 sin herramientas adicionales.

Requisitos previos. Ten instalado Visual Studio con la carga de trabajo «Desarrollo para el escritorio de .NET» en el host. En el equipo de compilación instala como mínimo .NET Framework 4.5 (valida la clave de registro HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Version).

Copiar Windows SDK y herramientas. Partiendo de la ruta predeterminada de instalación (%ProgramFiles%), copia recursivamente a la máquina de build, entre otras, las carpetas: Windows Kits 8.0 (bin, Catalogs, DesignTime, include, Lib, Redist, References), Microsoft SDKs Windows v8.0A (NETFX 4.0 Tools), Common Files\Merge Modules, y directorios clave de VC y MSBuild. Respeta los términos de licencia de cada kit instalado, especialmente si tienes WDk/ADK.

Además, traslada archivos específicos como msobj110.dll, mspdb110.dll, mspdbcore.dll, mspdbsrv.exe, msvcdis110.dll, makehm.exe, VCVarsQueryRegistry.bat y vsvars32.bat. Para ejecutar binarios en el servidor de compilación (p. ej., pruebas), copia también las runtimes de Visual C++ (msvcp110.dll, msvcr110.dll, atl110.dll, vcamp110.dll, etc.) a System32/SysWOW64 según arquitectura, y las variantes de depuración desde Debug_NonRedist (msvcp110d.dll, msvcr110d.dll, etc.).

Claves de Registro necesarias. Debes crear entradas para configurar valores de MSBuild. La raíz depende de la arquitectura: en x86, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft; en x64, HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft (en adelante %RegistryRoot%). Crea las siguientes entradas de tipo cadena (REG_SZ), reflejando los valores que tenga el host:

%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\VC7@11.0
%RegistryRoot%\VisualStudio\SxS\VS7@11.0
%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

En equipos x64 añade también: %RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x64@InstallationFolder. Si usarás MSBuild nativo de 64 bits (o TFS Build Service en x64), pon en el registro nativo de 64 bits estas entradas: HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\Setup\VS@ProductDir y los tres valores de HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0 para VCTargetsPath, VCTargetsPath10 y VCTargetsPath11.

Variables de entorno. La forma directa es ejecutar vcvarsall.bat desde …\VC\vcvarsall.bat. Puedes indicar la toolchain objetivo como argumento; si omites, se usa x86. Estos son los argumentos clave:

Argumento	Tipo de compilador	Host	Destino
x86	Nativo 32 bits	x86, x64	x86
x86_amd64	Cruzado a x64	x86, x64	x64
amd64	Nativo 64 bits	x64	x64

Si prefieres, puedes ajustar PATH manualmente añadiendo las rutas a Common7\IDE y a los directorios de MSBuild de 32/64 bits según corresponda, aunque usar vcvarsall.bat te evita olvidos.

GAC para ensamblados de MSBuild. Hay ensamblados adicionales que MSBuild requiere en la GAC. Copia desde el host a cualquier carpeta del build server y registra con gacutil -i (lo encontrarás en Microsoft SDKs\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

Compilación. En la línea de comandos del servidor, puedes invocar msbuild directamente o integrar el proceso en Azure Pipelines, que selecciona automáticamente el ejecutable MSBuild que corresponde a la arquitectura del agente. Un ejemplo básico sería: msbuild solution.sln.

Si necesitas un entorno portable y versionado en control de código fuente, puedes crear un «Depot» copiando los directorios a %Depot% y ajustando archivos MSBuild (Microsoft.CPP.Targets, etc.) para referenciar AssemblyFile=»$(VCTargetsPath11)Microsoft.Build.CppTasks.Common.v110.dll» en lugar de la GAC, además de usar un Partner.AutoImports.props con propiedades como VCTargetsPath, MSBuildExtensionsPath, VCInstallDir y WindowsSdkDir, importado al inicio de cada proyecto.

MSBuild, CMake y canalizaciones: métodos de compilación admitidos

Visual Studio te deja compilar desde el IDE, pero también con MSBuild en CLI, CMake y Azure Pipelines. Cada método aporta ventajas:

• IDE: compilaciones inmediatas, depuración integrada, compilación multiproceso y personalización de aspectos clave.
• CMake: unifica el sistema de build de C++ entre Linux y Windows sin proyectos .vcxproj, ideal si tu base ya es CMake.
• MSBuild (CLI): compila sin instalar todo Visual Studio, permite builds en paralelo y personalización amplia vía propiedades y targets.
• Azure Pipelines: integra CI/CD, ejecuta pruebas automatizadas y escala en la nube con tareas altamente personalizables.

Dentro del IDE puedes ajustar las configuraciones por plataforma (Windows o Linux) y por modo (Debug/Release), con opciones como directorios de salida, eventos de post-build, dependencias de proyectos, logs y supresión de warnings. Esta flexibilidad es esencial cuando gestionas múltiples arquitecturas o toolchains en una misma solución.

Flujo con CMake: compilar y depurar en Windows y Linux desde Visual Studio

Para bases de C++ que usan CMake, Visual Studio facilita abrir la carpeta del repo (con CMakeLists.txt), generar la caché automáticamente y configurar IntelliSense por objetivo. Desde ahí puedes crear configuraciones explícitas (p. ej., x64-Debug) que se conservan en CMakeSettings.json.

Un flujo típico parte de clonar el proyecto, por ejemplo: git clone https://github.com/bulletphysics/bullet3.git. Desde Visual Studio, abre el CMakeLists raíz y, tras la generación de caché, verás la «Vista de Destinos de CMake» con bibliotecas y ejecutables.

Para depurar en Windows, selecciona el ejecutable objetivo (por ejemplo, AppBasicExampleGui.exe en el SDK Bullet), coloca un breakpoint en una función clave (p. ej., mouseButtonCallback) y arranca con F5. Podrás inspeccionar variables, objetos, hilos y memoria con el depurador integrado.

Para Linux, agrega una configuración «Linux-Debug» en CMakeSettings, selecciona el generador «Archivos Make de Unix» si procede y conecta con la máquina remota por SSH (Visual Studio gestiona ssh/rsync, gdb, make y CMake en el host Linux). Se requieren las herramientas típicas (build-essential, gdb, rsync, make, zip) y una versión reciente de CMake (al menos 3.8; Microsoft proporciona binarios universales que puedes instalar con --prefix=/usr).

Si la app es de escritorio en Linux, puede hacer falta exportar DISPLAY. Obtén el valor con echo $DISPLAY y añade en launch.vs.json de la configuración el prefijo correspondiente en pipeArgs: por ejemplo, "export DISPLAY=:1;${debuggerCommand}" para asegurarte de que gdb inicie con el contexto gráfico correcto.

Una vez que el binario está ejecutándose en la máquina remota, Visual Studio trae al primer plano cuando se alcanza el breakpoint y muestra la pila de llamadas (por ejemplo, callbacks como CommonRigidBodyBase::mouseMoveCallback, X11OpenGLWindow::pumpMessage, etc.). Además, verás una consola con la salida remota y podrás enviar entrada estándar si hace falta.

Este enfoque te permite iterar en un único IDE tanto en Windows como en Linux, manteniendo mismas fuentes, distintos toolchains y una experiencia de depuración coherente.

Notas y consideraciones complementarias

Ten presente los límites oficiales: AOT nativo no soporta cross-OS sin virtualización/emulación, pero sí el intercambio de arquitecturas (x64 ↔ ARM64) dentro del mismo SO con la toolchain correcta. En Linux, presta atención a que las utilidades objcopy/strip que uses soporten el objetivo si has activado StripSymbols.

En escenarios de servidor, revisa los términos de licencia de cada componente que copies (Windows Kits, WDK, ADK, etc.). Microsoft advierte que estas guías se ofrecen «tal cual» y que los pasos no pueden probarse en todas las configuraciones posibles; es recomendable validar el pipeline en tu entorno antes de estandarizarlo.

Finalmente, cuando configures múltiples plataformas en una misma solución, nombra y separa bien tus configuraciones y salidas (por ejemplo, carpetas distintas por arquitectura/OS), automatiza con MSBuild y, si puedes, integra todo en una canalización CI/CD con Azure Pipelines para ganar repetibilidad y trazabilidad.

Con las cadenas de herramientas adecuadas, una configuración meticulosa de MSBuild/CMake y el soporte del IDE, resulta viable generar desde Windows binarios para distintas arquitecturas, orquestar builds en servidores sin VS, y mover el mismo código entre Windows y Linux con una experiencia de depuración homogénea y productiva para equipos mixtos.