Preguntas más frecuentes sobre el desarrollo de Aplicación de Windows

Para obtener información general sobre las opciones actuales para los desarrolladores de Windows, vea el episodio de Windows Chat de desarrollo Eligiendo su plataforma de desarrollo ideal, que analiza WinUI 3, .NET MAUI, React Native, Blazor y la Web Apps progresiva (PWA). Puede encontrar otros episodios en la lista de reproducción Windows Dev Chat.

También puede consultar la overview de las opciones de desarrollo de aplicaciones para desarrolladores de Windows.

En la era de los servicios en la nube, el desarrollo de aplicaciones de cliente sigue siendo importante para ofrecer interacciones ágiles y significativas en los dispositivos de los usuarios.

Este es el motivo por el que importan las aplicaciones cliente:

• Alcance del dispositivo: Las aplicaciones cliente permiten llevar la aplicación directamente a los usuarios en sus dispositivos que prefieran.
• puerta de enlace a Intelligent Services: Las aplicaciones cliente suelen ser las primeras interacciones que los usuarios tienen con los servicios. Ofrecen una interfaz enriquecida e interactiva que le permite mostrar características inteligentes y diferenciar su producto de otros.
• Escalabilidad con Integración en la Nube: Una aplicación cliente bien integrada puede sincronizarse sin esfuerzo con los servicios en la nube de back-end, lo que permite el acceso a datos en tiempo real y una escalabilidad sin contratiempos a medida que crece la base de usuarios.
• productividad mejorada y fidelidad del usuario: una aplicación diseñada cuidadosamente puede mejorar la productividad y mantener a los usuarios comprometidos con su producto o servicio a lo largo del tiempo.

El SDK de Aplicaciones para Windows proporciona componentes de servicio independientes para Windows aplicaciones de escritorio, como WinUI 3, ciclo de vida de la aplicación, ventanas, notificaciones, recursos y API de texto. Admite aplicaciones que se ejecutan en Windows 10, versión 1809 y versiones posteriores, siempre que estén dentro del ciclo de vida de soporte de la versión de Windows y de la versión de SDK de Aplicaciones para Windows.

Ambos son kits de desarrollo de software (SDK) que permiten compilar aplicaciones Windows.

El SDK de Aplicaciones para Windows proporciona componentes que se envían independientemente de Windows y funcionan en versiones de Windows compatibles hasta Windows 10, versión 1809. Incluye WinUI 3 y API para el ciclo de vida de la aplicación, ventanas, notificaciones, recursos, texto y otras funcionalidades.

El SDK de Windows proporciona encabezados, bibliotecas, metadatos y herramientas para las API del sistema operativo, como Win32, WinRT, COM, DirectX, dispositivos y funcionalidades de shell.

El SDK de Aplicaciones para Windows no reemplaza el SDK de Windows. Las aplicaciones que adoptan el SDK de Aplicaciones para Windows pueden seguir usando las API del SDK de Windows y las aplicaciones winUI 3 suelen usar ambas.

Estas son algunas razones para elegir un marco nativo de Windows para tu aplicación exclusiva para Windows:

• Performance: los marcos de Windows nativos están optimizados para aprovechar el hardware de Windows moderno, lo que proporciona experiencias de usuario rápidas y dinámicas.
• Integration: Windows incluye una amplia variedad de API que permiten experiencias sofisticadas que solo están disponibles en Windows. Los marcos nativos proporcionan una integración profunda con estas características y API.
• Native user experience: Native frameworks proporcionan una experiencia coherente en Windows dispositivos, lo que garantiza que la aplicación se ve y funciona perfectamente en todas partes.
• Compatibilidad sin conexión: Los marcos nativos admiten escenarios sin conexión, lo que permite que las aplicaciones funcionen incluso sin conectividad a Internet.
• Compatibilidad y herramientas: Microsoft mantiene los marcos nativos y proporciona SDK actuales, documentación, herramientas de depuración y ejemplos.

Si va a crear una nueva aplicación de escritorio de uso general Windows, se recomienda usar WinUI 3. WinUI 3 es el marco de interfaz de usuario nativo que se entrega con el SDK de Aplicaciones para Windows. Admite aplicaciones de escritorio de Windows y proporciona acceso a los controles de Fluent actuales y a las capacidades de la plataforma Windows.

Tenga en cuenta que WinUI 3 (un marco de interfaz de usuario) se incluye con el SDK de Aplicaciones para Windows (un marco de desarrollo de plataforma de Windows).

Puedes migrar la interfaz de usuario de una aplicación a WinUI 3 o usar islas XAML de WinUI para hospedar controles SDK de Aplicaciones para Windows en un host de escritorio existente compatible. Las islas XAML del sistema heredadas hospedan controles XAML para UWP y usan diferentes API.

Los elementos del SDK de Aplicaciones para Windows a menudo se pueden usar en aplicaciones de escritorio, en función de cómo se creó la aplicación existente. Las aplicaciones para UWP no son compatibles con SDK de Aplicaciones para Windows.

Esto significa que las aplicaciones WPF/MFC/WinForms pueden usar SDK de Aplicaciones para Windows API que no están relacionadas con WinUI 3. Algunos ejemplos son el ciclo de vida de la aplicación, la ventana y las notificaciones de la aplicación.

Consulte Use el SDK de Aplicaciones para Windows en un proyecto existente para obtener más información.

No. Las compilaciones XAML de WinUI 3 usan MSBuild, pero puedes compilar con el SDK de .NET y las plantillas actuales de WinUI 3 desde la línea de comandos en otro editor. Consulte el inicio rápido de la línea de comandos.

Visual Studio 2026 proporciona la experiencia más completa de edición, depuración, generación de perfiles y Recarga activa XAML. Use el flujo de trabajo que coincida con los requisitos de herramientas.

Este error suele producirse en unpackaged escenarios de aplicación en los que el entorno de ejecución de SDK de Aplicaciones para Windows no se ha instalado en el equipo. Pruebe lo siguiente:

• Si está ejecutando una aplicación packaged (el valor predeterminado recomendado), asegúrese de que está iniciando a través de Visual Studio con el MsixPackage perfil de inicio seleccionado (no el perfil ejecutable sin formato). El paso de empaquetado MSIX instala los componentes de tiempo de ejecución necesarios.
• Si ejecuta una aplicación sin empaquetar dependiente del entorno de ejecución, instale el entorno de ejecución correspondiente de SDK de Aplicaciones para Windows. Una implementación independiente incluye sus dependencias de SDK de Aplicaciones para Windows.
• Confirme que el proyecto coincide con el modelo de implementación. Para una aplicación .NET normal sin empaquetar, la configuración <WindowsPackageType>None</WindowsPackageType> habilita SDK de Aplicaciones para Windows inicialización automática en tiempo de ejecución. Use la API del bootstrapper directamente solo cuando necesite un control explícito sobre la inicialización de dependencias dinámicas.

Consulte Deploy apps that use the SDK de Aplicaciones para Windows para obtener más información sobre los requisitos de implementación.

WinUI 3 es Microsoft marco de interfaz de usuario nativo actual para aplicaciones de escritorio de Windows y se entrega como parte del SDK de Aplicaciones para Windows.

WinUI 2, también denominado WinUI para UWP, es una biblioteca de controles y estilos para aplicaciones para UWP. WinUI 2 y WinUI 3 usan diferentes espacios de nombres XAML y no son compatibles con binarios.

Sí. La aplicación WinUI 3 es el término más claro para una aplicación cuya interfaz de usuario usa WinUI 3 y la SDK de Aplicaciones para Windows. La aplicación WinUI también se usa normalmente cuando el contexto no es ambiguo.

No. SDK de Aplicaciones para Windows no se puede usar en aplicaciones para UWP y WinUI para UWP no se puede mezclar con WinUI 3. Consulta Migrate de UWP a la SDK de Aplicaciones para Windows.

UWP y WinUI 3 comparten muchos conceptos xaml, pero la migración no es un cambio directo en el espacio de nombres. El costo depende principalmente de:

1. Archivo del proyecto y personalización de MSBuild: El esfuerzo de migración varía en función del uso avanzado de MSBuild.
2. Migración de API de .NET: las aplicaciones para UWP que usan .NET Native pueden pasar a una versión de .NET compatible actualmente con AOT nativo. Esta modernización es independiente de migrar la interfaz de usuario a WinUI 3.
3. Bibliotecas de componentes de interfaz de usuario: Las bibliotecas deben tener versiones destinadas a WinUI 3.
4. API de ventanas y modelo de aplicación: Las API de UWP asociadas a conceptos como CoreWindow, ApplicationViewo GetForCurrentView requieren SDK de Aplicaciones para Windows reemplazos u otro enfoque de escritorio.
5. Proyección del lenguaje C++: Si la aplicación para UWP usa la proyección de C++/CX reemplazada, porte ese código a C++/WinRT.

Para obtener más información, consulta Migrar de UWP a SDK de Aplicaciones para Windows y la correspondencia de API de UWP a SDK de Aplicaciones para Windows.

Sí, las aplicaciones actualizadas se pueden publicar sin actualizar la identidad de la aplicación. Los usuarios de la versión anterior se actualizarán a la nueva versión. Esto solo se aplica a las aplicaciones de escritorio. Xbox, HoloLens y aplicaciones estándar de Surface Hub no se pueden migrar a WinUI 3.

Consulte Introducción a la implementación.

Consulta Migrate de UWP a la SDK de Aplicaciones para Windows.

No. Los controles de la interfaz de usuario se pueden crear en el código. Sin embargo, representar la interfaz de usuario en marcado XAML declarativo proporciona muchas ventajas, incluida una experiencia de desarrollador mejorada.

• Migración de UWP a WinUI 3: muchos conceptos de XAML y de interfaz de usuario se transfieren, pero los espacios de nombres, el modelo de proyecto y algunas API difieren.
• Migración de WPF a WinUI 3: muchos conceptos se transfieren, pero el conjunto de controles y las API difieren.

Actualmente no. Usa xaml Recarga activa, Árbol visual dinámico, Explorador de propiedades en directo y herramientas en tiempo de ejecución relacionadas para inspeccionar y actualizar XAML mientras se ejecuta la aplicación.

Para ver un tutorial completo de las herramientas de diseño en tiempo de ejecución disponibles para WinUI 3, consulta Herramientas de diseño en tiempo de ejecución XAML para WinUI 3.

Sí. WinUI 3 se distribuye como parte del SDK de Aplicaciones para Windows.

No. WinUI para UWP forma parte de la plataforma para UWP.

No del todo. Aunque WinUI 3 se inició desde el código base de WinUI para UWP, son tecnologías distintas. Ambos son marcos de interfaz de usuario basados en XAML que funcionan entre .NET y C++, pero WinUI para UWP y WinUI 3 no son compatibles entre sí.

No. WinUI 3 se distribuye como parte del SDK de Aplicaciones para Windows.

Sí. Las API de WinUI 3 y muchas SDK de Aplicaciones para Windows funcionan en aplicaciones sin empaquetar. Sin embargo, algunas funcionalidades de Windows requieren la identidad del paquete y las aplicaciones sin empaquetar dependientes del marco deben inicializar el entorno de ejecución de SDK de Aplicaciones para Windows. Compare las opciones de Introducción al empaquetado y Características que requieren la identidad del paquete.

WinUI 3 es el marco de interfaz de usuario incluido en el SDK de Aplicaciones para Windows. Las islas XAML son una técnica de hospedaje que permite que una aplicación de escritorio existente coloque contenido XAML junto con la interfaz de usuario desde otro marco.

El término puede hacer referencia a islas XAML del sistema heredadas que hospedan controles XAML de UWP o a islas XAML de WinUI que hospedan controles SDK de Aplicaciones para Windows en hosts de escritorio admitidos. Las API, los espacios de nombres y los requisitos de host difieren.

Los controles WinUI 3 usan el estilo Fluent en versiones compatibles de Windows 10 y Windows 11, tanto en aplicaciones empaquetadas como sin empaquetar. Algunos efectos y comportamientos del sistema operativo varían según la versión de Windows. Por ejemplo, Mica está disponible en Windows 11 y vuelve a un color sólido en Windows 10.

Sí. Desktop Acrylic es compatible con Windows 10, versión 1809 y posteriores. Mica requiere Windows 11 y recurre a un color de tema sólido en Windows 10. Llame a MicaController.IsSupported o DesktopAcrylicController.IsSupported en tiempo de ejecución antes de aplicar un telón de fondo. Consulte cómo aplicar Mica o Acrílico en aplicaciones de escritorio para Windows 11.

Consulte Ejemplo y recursos. Algunos repositorios destacados:

• WindowsAppSDK-Samples: muestra cómo usar conjuntos de API de SDK de Aplicaciones para Windows específicos.
• Ejemplos de Windows específicos del tema: contiene el ejemplo usado en el tutorial Crear la aplicación de notas de WinUI 3.
• WinUI 3 Gallery: Muestra WinUI y SDK de Aplicaciones para Windows. También está disponible en el Microsoft Store.

Si ya ha invertido mucho en WPF, puede seguir usándolo para las aplicaciones existentes. WPF es un marco estable y maduro que se usa ampliamente para compilar aplicaciones de escritorio Windows.

Usa la actualización de GitHub Copilot para evaluar y actualizar una aplicación WPF de .NET Framework a .NET moderno. Revise el plan generado y valide cada cambio en la aplicación.

Al desarrollar una aplicación de WPF con .NET 9 o posterior, puedes asegurarte de que tu aplicación coincida con el aspecto elegante y moderno de Windows 11. El nuevo tema Fluent para WPF presenta una estética contemporánea de Windows 11, con el modo de luz y oscuro integrado y la compatibilidad con el color de énfasis del sistema. Esto moderniza la apariencia de la aplicación y ofrece una experiencia de usuario pulida y cohesiva.

Si WinForms satisface sus necesidades y su equipo está cómodo con él, puede seguir usando WinForms para las aplicaciones existentes. WinForms es un marco estable y maduro que se usa ampliamente para el desarrollo de Windows escritorio.

El equipo de WinForms continúa invirtiendo en la plataforma. El trabajo reciente y continuo incluye:

• API de cuadros de diálogo y formulario asincrónico
• Compatibilidad con el modo oscuro y los estilos visuales
• Mejoras de accesibilidad, valores altos de PPP, diseño y diseñador
• Modernización del portapapeles y de DataObject

Si tiene como destino usuarios en varias plataformas de sistema operativo, la creación de aplicaciones multiplataforma con .NET MAUI o React Native puede ofrecer varias ventajas:

• Alcanzar: Las aplicaciones multiplataforma llegan a un público mayor en diferentes dispositivos y sistemas operativos.
• Reutilización del código: La reutilización del código entre plataformas reduce el tiempo de desarrollo y el costo. La creación de aplicaciones independientes para Windows, Android, iOS y macOS puede ser prohibitivamente costosa.
• Experiencia coherente del usuario: Los marcos multiplataforma ayudan a proporcionar una apariencia coherente entre plataformas.
• Integración: Las aplicaciones multiplataforma todavía se pueden integrar con servicios específicos de la plataforma para ofrecer una experiencia completa.

Al compilar una aplicación de .NET MAUI para Windows, la salida usa WinUI 3. Durante el desarrollo, .NET MAUI ofrece una única experiencia de .NET entre plataformas, pero genera código específico de la plataforma en segundo plano.

.NET MAUI proporciona una experiencia de .NET unificada en Windows, iOS, Android y macOS. Ofrece API multiplataforma para funcionalidades comunes, como almacenamiento, redes y sensores de dispositivo. También puede llamar a API específicas de la plataforma o proporcionar implementaciones especializadas para cada plataforma.

No en este momento. Aunque .NET MAUI usa WinUI 3 al ejecutarse en Windows, los equipos que esperan tener como destino varias plataformas deben comenzar con .NET MAUI o React Native para escritorio.

Es posible que los equipos con experiencia de desarrollo web sólida quieran considerar React Native for Desktop. Incluye React Native para Windows y macOS. Con el enfoque "Learn once, write anywhere", se pueden usar las aptitudes existentes de JavaScript, TypeScript y React para compilar aplicaciones nativas de Windows y macOS.

React Native for Desktop representa la interfaz de usuario (UI) directamente en primitivos nativos, proporcionando rendimiento y capacidades nativas de la plataforma.

Consulte la documentación de React Native for Desktop para empezar.

React Native para Windows admite las versiones de Windows enumeradas en su documentación de compatibilidad. Compruebe la compatibilidad con la familia de dispositivos para la versión de React Native para Windows que tenga como destino en lugar de suponer que se admiten todos los dispositivos Windows.

Para una aplicación de Xbox, usa UWP y ten en cuenta las limitaciones específicas de UWP para Xbox. Para el desarrollo de juegos, usa el Kit de desarrollo de juegos de Microsoft.

Para un Surface Hub que ejecuta el entorno estándar de Teams Rooms o Surface Hub, usa una aplicación UWP que cumpla los requisitos de aplicaciones para Surface Hub. Un Surface Hub 3 configurado con Windows 11 Pro o Enterprise puede ejecutar tecnologías de aplicaciones de escritorio compatibles, por lo que UWP no es la única opción en esa configuración.

Las aplicaciones híbridas combinan lo mejor del desarrollo de aplicaciones web y nativas. Su núcleo se basa en tecnologías web como HTML, CSS y JavaScript, y está envuelto en un contenedor nativo que proporciona acceso a ciertas características nativas de la plataforma y hardware. También se pueden distribuir a través de tiendas de aplicaciones.

La principal ventaja es que las aplicaciones híbridas permiten crear una sola aplicación que se puede ejecutar en varias plataformas nativas y en la web, lo que reduce el tiempo de desarrollo y el costo. Entre los ejemplos de plataformas de desarrollo de aplicaciones híbridas se incluyen:

• Electron para aplicaciones de escritorio
• Ionic para aplicaciones móviles
• .NET MAUI Blazor Hybrid para aplicaciones multiplataforma

Consulte Desarrollo web en Windows y Descripción general de las aplicaciones web progresivas.

Con .NET MAUI, las aplicaciones Blazor se pueden ejecutar de forma nativa en Windows, iOS, Android y macOS. Esto le permite crear aplicaciones cliente híbridas que combinen los componentes blazor y .NET MAUI en una sola aplicación cliente nativa, con acceso completo a las funcionalidades de la plataforma nativa.

Obtenga más información en ASP.NET Core Blazor Hybrid.

No. A partir de .NET 9, .NET MAUI incluye un control HybridWebView que permite hospedar otras interfaces de usuario basadas en JavaScript dentro de una aplicación nativa.

Esto permite hospedar angular, React, Vue u otras aplicaciones HTML/JavaScript dentro de una aplicación de .NET MAUI. El control híbrido proporciona interoperabilidad entre C# y JavaScript, por lo que el código de C# puede llamar a funciones de JavaScript y viceversa.

Sí. WPF y aplicaciones winForms también pueden hospedar componentes híbridos de Blazor, lo que permite agregar la interfaz de usuario web moderna a las aplicaciones existentes. Esto no se admite para aplicaciones de WPF o WinForms basadas en .NET Framework.

Los componentes nativos e híbridos se pueden mezclar dentro de una aplicación. Por ejemplo, el núcleo de una aplicación se puede compilar con componentes de .NET MAUI, mientras que los componentes híbridos proporcionan funcionalidad adicional. Esto permite combinar el rendimiento y las funcionalidades de los componentes nativos con la flexibilidad y la rentabilidad de los componentes híbridos.

Web apps ofrecen el alcance más amplio de cualquier plataforma de aplicaciones cliente. Entre las opciones para crear hermosas aplicaciones web .NET se incluyen:

• Las aplicaciones de ASP.NET Core con Razor Pages
• aplicaciones de ASP.NET Core MVC
• Aplicaciones ASP.NET Core Blazor, con opciones de modelo de hospedaje.
  • WebAssembly de Blazor
  • Blazor Server

Los modelos de hospedaje de Blazor ahora se pueden configurar en el nivel de componente, lo que permite escenarios como hospedar un componente WebAssembly de Blazor dentro de una aplicación blazor Server.

Consulte la documentación ASP.NET Core para obtener más información.

Windows es una plataforma abierta que admite muchas tecnologías. Estos son algunos criterios que pueden ayudarle a elegir una plataforma:

• ¿Está creando Windows primero o multiplataforma?
• ¿Qué lenguajes o aptitudes ya tiene: .NET, JavaScript, otra cosa?
• ¿Necesita acceso a las API específicas de Windows?
• ¿Qué funcionalidades del marco se ajustan mejor a los requisitos de la aplicación?
• Consulte esta tabla para obtener más factores de comparación.

Para muchas aplicaciones empresariales, los equipos suelen elegir en función de las aptitudes existentes y de lo que el equipo es más cómodo usar.

Tenga en cuenta lo siguiente al elegir un enfoque de desarrollo para la aplicación web:

• Blazor se recomienda para crear aplicaciones web de front-end con .NET. Le permite crear tanto el front-end como el back-end mediante .NET, ahorrar tiempo y costo, y es especialmente bueno para las aplicaciones empresariales.
• Las aplicaciones web de JavaScript siguen teniendo sentido si desea aprovechar las habilidades existentes de JavaScript o si necesita integrarse con las bibliotecas o marcos de JavaScript establecidos.
• Las aplicaciones existentes que usan marcos más antiguos, como Web Forms, MVC o Razor Pages, siguen siendo compatibles y se pueden seguir desarrollando y manteniendo.

Microsoft Fotos es un ejemplo documentado. La aplicación migrada de UWP a la SDK de Aplicaciones para Windows y sigue usando WinUI 3. Para obtener más información sobre la arquitectura y la migración, consulta Microsoft Fotos: Migración de UWP a SDK de Aplicaciones para Windows.

Las organizaciones usan .NET MAUI para crear aplicaciones multiplataforma para Android, iOS, macOS y Windows. Consulte ejemplos en la presentación de clientes de .NET.

La mayoría de la interfaz de usuario de Microsoft Visual Studio se compila con WPF. El propio IDE Visual Studio es un ejemplo importante de una aplicación de WPF compleja y de alto rendimiento.

El sistema aéreo FlightPulse de GE Digital usa Blazor para la configuración de back-end de todo lo que ven los pilotos, lo que aporta datos y análisis de sensores directamente a los pilotos para mejorar la seguridad y la eficiencia.

Consulte más Blazor customer stories en el sitio de .NET.

Use C# (.NET) en la mayoría de los casos. C# ofrece un desarrollo más rápido, seguridad de memoria, bibliotecas enriquecidas y excelentes herramientas. La mayoría de las aplicaciones Windows ( incluidas WinUI 3, WPF, WinForms y aplicaciones de .NET MAUI) se compilan mejor con C#.

Use C++ cuando necesite acceso directo a hardware, sobrecarga mínima en tiempo de ejecución o interoperabilidad con código base de C++ existente. Entre los escenarios comunes de C++ se incluyen motores de juegos (DirectX), controladores, utilidades de nivel de sistema y componentes críticos para el rendimiento.

Factor	C# (.NET)	C++
Velocidad de desarrollo	✅ Más rápido: memoria administrada, ecosistema enriquecido	⚠️ Más lento: administración manual de recursos
Rendimiento en tiempo de ejecución	✅Excelente con .NET moderno (AOT, Span<T>)	✅ Lo mejor posible: no hay pausas de GC
Seguridad de memoria	✅Recolector de elementos no utilizados	⚠️ Manual: riesgo de fugas y vulnerabilidades
Acceso a la API de Windows	✅ Mediante la proyección de C#/WinRT	✅ Mediante la proyección de C++/WinRT
Compatibilidad con WinUI 3	✅ Compatibilidad completa	✅ Compatibilidad completa a través de C++/WinRT
Multiplataforma	✅.NET se ejecuta en Windows, Linux, macOS	✅ Con código específico de la plataforma
Más adecuado para	Aplicaciones empresariales, CRUD, servicios, aplicaciones con mucha interfaz de usuario	Juegos, controladores, herramientas del sistema, baja latencia

También puedes combinar ambos: compilar la aplicación en C# y llamar al código nativo crítico para el rendimiento a través de P/Invoke (CsWin32) o un componente de C++/WinRT.

Usa CsWin32, un generador de código fuente que crea signaturas de P/Invoke con seguridad de tipos en tiempo de compilación. Agregue el Microsoft.Windows.CsWin32 paquete NuGet, enumere las API que necesita en un NativeMethods.txt archivo y llámelas a través de una clase generada PInvoke .

CsWin32 reemplaza las declaraciones escritas [DllImport] a mano y funciona en cualquier proyecto de C#, incluidos WinUI 3, WPF, WinForms y aplicaciones de consola. Consulte Llamar a las API de Win32 desde una aplicación de Windows de C# (CsWin32) para ver un tutorial paso a paso.

C++/WinRT es una proyección estándar del lenguaje C++17 para Windows Runtime API. Úselo al compilar aplicaciones Windows en C++ que consumen o crean API de WinRT. Reemplaza a C++/CX y a la Biblioteca de plantillas de C++ para Windows Runtime (WRL).

Elija C++/WinRT cuando:

• Está creando una aplicación de WinUI 3 en C++
• Debe crear componentes de Windows Runtime consumidos por otros lenguajes.
• Está migrando de C++/CX

C#/WinRT proporciona compatibilidad con la proyección de WinRT para C#. En la mayoría de los casos, no interactúas directamente con ello: las aplicaciones .NET dirigidas a Windows obtienen automáticamente acceso a las API de WinRT a través de identificadores de marcos de destino (TFM). Necesita C#/WinRT explícitamente al crear componentes de Windows Runtime en C# o al generar ensamblados de interoperabilidad para componentes de WinRT de terceros.

Una aplicación empaquetada contiene sus archivos, identidades e información de implementación en un paquete como MSIX. Una aplicación sin empaquetar usa un instalador o un proceso de implementación fuera del sistema de paquetes de Windows y no tiene la identidad del paquete de forma predeterminada. Una aplicación empaquetada con ubicación externa usa un paquete de identidad pequeño mientras conserva los archivos binarios ubicados externamente y su instalador existente y su proceso de actualización.

Consulte Información general sobre el empaquetado para conocer los requisitos y los inconvenientes.

Depende de las características de Windows que usa la aplicación. La identidad del paquete es necesaria para escenarios como tareas en segundo plano empaquetadas, destinos de recursos compartidos, tareas de inicio, extensiones de paquete de menú contextual personalizadas, asociaciones de protocolo y tipo de archivo basadas en manifiestos, y muchas API de IA de Windows. Las notificaciones push de SDK de Aplicaciones para Windows admiten escenarios limitados en primer plano sin identidad, pero la entrega en segundo plano y la activación COM requieren identidad. Las notificaciones de aplicación local y WinUI 3 pueden funcionar sin identidad de paquete.

Consulte Características que requieren la identidad del paquete. Si necesita identidad, pero debe conservar un instalador existente, considere la posibilidad de empaquetar con ubicación externa.

Una aplicación dependiente del entorno usa los paquetes en tiempo de ejecución de SDK de Aplicaciones para Windows instalados por separado en el dispositivo. Esto reduce el tamaño de implementación de la aplicación y permite que el marco instalado reciba actualizaciones de mantenimiento. Una aplicación independiente lleva sus dependencias SDK de Aplicaciones para Windows con ella, lo que aumenta el tamaño de implementación y hace que el publicador de la aplicación sea responsable de distribuir SDK de Aplicaciones para Windows actualizaciones de mantenimiento con nuevas versiones de la aplicación.

Las API que dependen de paquetes MSIX adicionales, como el paquete Singleton, pueden requerir comprobaciones de implementación o en tiempo de ejecución independientes, incluso en una aplicación independiente. El empaquetado y la implementación en tiempo de ejecución son decisiones independientes. Consulte Información general de la implementación del SDK para aplicaciones de Windows.

Una aplicación winUI 3 se puede entregar a través de la Microsoft Store, un .appinstaller archivo o un archivo MSI o un ejecutable de instalación. Los paquetes de Store se pueden actualizar mediante el servicio de Microsoft Store, en función de la configuración de Store y de la organización. Una implementación .appinstaller admite actualizaciones automáticas solo cuando su UpdateSettings configura comprobaciones en tiempo de inicio o en segundo plano. Las implementaciones msi y de instalación deben proporcionar o integrar su propio mecanismo de actualización.

Sí, para algunos escenarios. Actualmente, los proyectos XAML de WinUI 3 requieren MSBuild, aunque no es necesario Visual Studio y dotnet build puede invocar MSBuild desde la línea de comandos. Puedes usar las API no XAML de SDK de Aplicaciones para Windows en proyectos de C++ y CMake a través de la versión preliminar de CLI de desarrollo de Aplicación de Windows, o integrar manualmente el entorno de ejecución.

Las tres primeras tecnologías forman parte de Microsoft Foundry en Windows. Puede combinarlos entre sí y con modelos en la nube en la misma aplicación:

• Use las API de IA de Windows para capacidades listas para usar cuyos modelos y cuya aceleración de hardware administra Windows.
• Use Foundry Local para detectar, descargar y ejecutar modelos de voz y lenguaje de código abierto compatibles localmente.
• Use Windows ML para ejecutar sus propios modelos ONNX con proveedores de ejecución para hardware de CPU, GPU y NPU disponibles.
• Use Microsoft Foundry, una plataforma de inteligencia artificial en la nube independiente, cuando necesite modelos hospedados en la nube, recuperación, gobernanza centralizada o funcionalidades que no estén disponibles en el dispositivo de destino.

Compare las opciones de Choose your Windows AI solution (Elegir la solución de inteligencia artificial de Windows). Considere la funcionalidad del modelo, la privacidad, la conectividad, la latencia, la cobertura de hardware, el tamaño de la implementación y el costo operativo.

No todos ellos. Muchas Windows API de IA requieren una Copilot+ PC, pero algunas API también admiten GPU o CPU específicas. Foundry Local y Windows ML admiten configuraciones de hardware más amplias, sujetas a sus requisitos actuales del sistema operativo, el modelo, el entorno de ejecución y el proveedor de ejecución.

Consulte la tabla de hardware de la API de IA de Windows y los requisitos de la API o el modelo específicos. Detecte la compatibilidad y la preparación del modelo en tiempo de ejecución, y proporcione una alternativa sin IA, con modelo local o en la nube cuando la función no esté disponible.

Sí. Las API de IA de Windows, Foundry Local y Windows ML pueden ejecutar inferencias en el dispositivo del usuario, lo que puede reducir la latencia y mantener los datos de entrada en el dispositivo. Algunos modelos o proveedores de ejecución deben descargarse o aprovisionarse en primer lugar y pueden requerir una conexión a Internet durante la instalación o el mantenimiento. Los servicios de inteligencia artificial en la nube requieren conectividad y envían datos al servicio según sus términos de control de datos.

Indique a los usuarios cuándo se requiere una descarga de modelos y cuándo los datos abandonan el dispositivo. No describa una función como apta para usarse sin conexión hasta que haya probado por completo su comportamiento en la primera ejecución, la actualización y el mecanismo alternativo.

Sí. Los agentes de IA para programar pueden ayudar a crear la estructura base de proyectos, explicar APIs, migrar código, generar pruebas y diagnosticar problemas de compilación. Use la guía de desarrollo de Windows asistida por IA para GitHub Copilot, el complemento del agente de WinUI, el servidor MCP de Microsoft Learn, los flujos de trabajo de migración y las pruebas asistidas por IA.

Revise y pruebe el código generado como haría con cualquier otra contribución. En concreto, compruebe los nombres y versiones de las API, las funcionalidades de paquete, el código sensible a la seguridad, la accesibilidad y las sustituciones de UWP a WinUI 3.

Defina el uso y las limitaciones previstos de la característica, evalúe la calidad y la seguridad con datos representativos, revele el comportamiento de la inteligencia artificial cuando corresponda, proteja los datos del usuario y proporcione una reserva cuando el modelo o el hardware necesario no estén disponibles. Mantenga los secretos y las credenciales de servicio con privilegios fuera de las aplicaciones cliente y requiera confirmación del usuario antes de acciones consecuentes o irreversibles. Consulte Desarrollo responsable de IA generativa en Windows y Seguridad e IA responsable para el desarrollo en Windows.

Consulte Windows desarrollo de aplicaciones: Procedimientos recomendados y Windows información general sobre el rendimiento y los aspectos básicos de las aplicaciones.

El SDK de Aplicaciones para Windows tiene un sistema operativo mínimo compatible con Windows 10, versión 1809, compilación 17763. El soporte técnico de Microsoft requiere una versión compatible de SDK de Aplicaciones para Windows con la actualización de mantenimiento más reciente, así como una edición, una versión y un canal de mantenimiento de Windows que sigan siendo compatibles. Las API individuales pueden requerir una versión de Windows más reciente o hardware específico. Consulte soporte técnico de SDK de Aplicaciones para Windows y canales de lanzamiento.

Sí. Cree una aplicación nativa de Arm64 para obtener el mejor rendimiento y eficacia. Para un código base de C++ grande con dependencias x64, Arm64EC le permite migrar módulos de forma incremental. Windows 11 en Arm también puede ejecutar muchas aplicaciones x86 y x64 existentes a través de la emulación prisma, pero debe probar el rendimiento y la compatibilidad en dispositivos Arm representativos.

UWP y WinUI 2 no están en desuso formalmente. Visual Studio 2026 admite UWP con .NET moderno y AOT nativo, mientras que WinUI 2.8 sigue siendo la versión estable más reciente de WinUI para UWP. Sin embargo, Microsoft recomienda WinUI 3 y el SDK de Aplicaciones para Windows para las nuevas aplicaciones de escritorio de uso general Windows.

La compatibilidad con UWP para .NET moderna con AOT nativo está disponible con carácter general y es el tipo de proyecto de UWP de C# predeterminado en Visual Studio 2026. Migrar una aplicación UWP existente de .NET Native a la versión moderna de .NET es un paso de modernización independiente de la migración de su interfaz de usuario a WinUI 3. Consulta Moderniza tu aplicación UWP con .NET y AOT nativo.

Los desarrolladores de UWP no deben sentirse presionados para migrar si están satisfechos con UWP y su conjunto de características, para muchas aplicaciones, la opción adecuada puede ser permanecer en UWP.

Las aplicaciones que quieran beneficiarse de la plataforma de Windows más reciente y las inversiones de .NET deben considerar la posibilidad de pasar a WinUI 3 y al SDK de Aplicaciones para Windows. Consulta Migrate de UWP a la SDK de Aplicaciones para Windows.

Siga usando UWP cuando el modelo de aplicación o dispositivo de destino lo requiera, como aplicaciones de Xbox, aplicaciones HoloLens 2D o aplicaciones para el entorno estándar de Surface Hub. Windows IoT Enterprise admite tecnologías de aplicaciones de escritorio, incluida la SDK de Aplicaciones para Windows, por lo que un destino de IoT no es por sí mismo una razón para usar UWP.

No. WPF es compatible y sigue recibiendo mejoras en características, rendimiento, accesibilidad y estilo Fluent en las versiones modernas de .NET. Sigue siendo una buena opción para las aplicaciones de WPF existentes y para las nuevas aplicaciones cuyos requisitos se ajustan a WPF. Para las nuevas aplicaciones de escritorio de uso general Windows, la recomendación principal de Microsoft es WinUI 3 con el SDK de Aplicaciones para Windows. Consulte la hoja de ruta WPF sobre GitHub.

No. WinForms se admite y sigue recibiendo actualizaciones de características. Consulte la hoja de ruta Windows Forms sobre GitHub.

No. WinRT es una interfaz binaria de aplicación (ABI) que permite la interoperabilidad entre varios lenguajes. WinRT es la evolución de COM y el SDK de Aplicaciones para Windows proporciona la mayor parte de su funcionalidad a través de las API de WinRT.

Consulte las notas de la versión de SDK de Aplicaciones para Windows para obtener versiones estables, preliminares y experimentales. La página Novedades para los desarrolladores de Windows resume las actualizaciones más recientes del SDK de Windows, SDK de Aplicaciones para Windows, WinUI 3, las herramientas y la plataforma.