Introducción al empaquetado

El empaquetado define cómo se instala, actualiza e integra la aplicación con Windows. Las aplicaciones winUI 3 se empaquetan de forma predeterminada, mientras que muchas aplicaciones de escritorio, como las aplicaciones win32 tradicionales, se ejecutan sin empaquetar. Elegir entre una aplicación empaquetada o desempaquetada afecta a las características que puede usar, el modelo de implementación en el que confía y la experiencia general que obtienen los clientes.

Nota:

¿Crear una nueva aplicación WinUI 3? Ya está empaquetado de forma predeterminada. Las instrucciones siguientes son más relevantes para los desarrolladores que necesitan elegir explícitamente, normalmente al migrar una aplicación existente, implementar en máquinas empresariales o agregar características de Windows a una aplicación que no se empaquetaba originalmente.

¿Por qué importa el empaquetado de aplicaciones?

Las aplicaciones empaquetadas se benefician de un modelo de instalación limpio, actualizaciones automáticas y acceso a las características de Windows que requieren la identidad del paquete, incluidas las tareas en segundo plano, las notificaciones, las extensiones de menú contextual, los destinos de recurso compartido y otros puntos de extensibilidad. El empaquetado también ayuda a garantizar implementaciones más limpias, actualizaciones confiables y distribución simplificada a través de canales como las herramientas de implementación empresarial y Microsoft Store.

Características que requieren la identidad del paquete

Estas características de Windows solo funcionan en aplicaciones que tienen identidad de paquete, ya sea a través del empaquetado MSIX completo o paquete con ubicación externa (empaquetado disperso).

Feature Descripción
Tareas en segundo plano Ejecute código cuando la aplicación no esté en primer plano, por ejemplo, para sincronizar datos, procesar descargas o responder a eventos del sistema.
Windows API de IA (PhiLice, OCR, etc.) Acceda a funcionalidades de inteligencia artificial en el dispositivo, como modelos de lenguaje local, reconocimiento de texto e análisis de imágenes.
Notificaciones push (WNS) Reciba notificaciones en tiempo real del servicio en la nube a través del servicio de notificaciones de Windows.
Destino de compartición Permitir que los usuarios compartan contenido de otras aplicaciones directamente en la suya a través de la hoja Compartir del sistema.
Extensiones de menú contextual personalizadas Agregue las acciones de tu aplicación al menú contextual en el Explorador de archivos y otras superficies de interfaz.
Asociaciones de protocolo y tipo de archivo Registre la aplicación como controlador para tipos de archivo específicos o protocolos de URI (por ejemplo, yourapp://).
Tareas de inicio Inicie la aplicación automáticamente cuando el usuario inicie sesión en Windows.
App Services Exponga servicios en segundo plano a los que otras aplicaciones puedan llamar, lo que permite la comunicación entre aplicaciones.

Sugerencia

Si no está empaquetado y se produce un error E_ILLEGAL_METHOD_CALL o APPMODEL_ERROR_NO_PACKAGE al llamar a las API de Windows, se debe a el requisito de identidad del paquete. Vea el empaquetado con ubicación externa (empaquetado disperso) como la solución de fricción más baja.

Para detectar en tiempo de ejecución si el proceso tiene identidad de paquete, use GetCurrentPackageFullName : consulte ¿Este proceso empaquetado? en el blog Inside MSIX para ejemplos canónicos de C++ y C#.

Para obtener más información, consulte Características que requieren la identidad del paquete.

Empaquetamiento de modelos de un vistazo

Modelo Identidad del paquete Instalador Store elegible Más adecuado para
Empaquetado (MSIX) ✅ Sí MSIX reemplaza el instalador ✅ Sí (envío MSIX) Nuevas aplicaciones, publicación en la Tienda, MDM empresarial
Empaquetado con ubicación externa ✅ Sí El instalador existente ✅ Sí (envío MSI/EXE) Aplicaciones existentes que tienen su propio instalador, vendedores de software independientes
Desempaquetado ❌ No Instalador MSI o EXE (también: XCopy o script para la distribución fuera de la Store) ✅ Sí (envío MSI/EXE: requiere un instalador MSI o EXE con compatibilidad de instalación silenciosa) Amplia distribución de Win32, herramientas internas

Aplicaciones empaquetadas (MSIX)

Las aplicaciones empaquetadas usan MSIX y tienen package identity, que es necesario para muchos puntos de extensibilidad Windows. La identidad del paquete permite Windows identificar de forma confiable el autor de la llamada de las API de la plataforma, por lo que estas características dependen de ella.

  • Las aplicaciones empaquetadas normalmente se ejecutan en un contenedor ligero de aplicaciones con virtualización del registro y sistema de archivos (consulte AppContainer para aplicaciones heredadas y aplicaciones AppContainer msix).
  • Las aplicaciones también se pueden configurar para que no se ejecuten en un contenedor de aplicaciones si es necesario.
  • MSIX se usa tanto para el empaquetado como para la instalación (consulte ¿Qué es MSIX?).

Empaquetado con ubicación externa (empaquetado disperso)

El empaquetado con ubicación externa (también denominado paquetes dispersos) permite registrar un paquete de identidad pequeño junto con la aplicación existente, sin cambiar el instalador, las ubicaciones binarias ni el proceso de actualización. Se introdujo en Windows 10 versión 2004 (compilación 19041).

Este es el punto óptimo para las aplicaciones Win32/WPF/WinForms existentes que se envían a través de su propio instalador (NSIS, WiX, InstallShield, etc.) y no quieren reemplazarlo por MSIX. Registra un paquete de identidad ligero; tus archivos binarios permanecen donde están, y desbloqueas el conjunto completo de características de Windows protegidas por la identidad del paquete.

Capacidad MSIX Ubicación externa
Reemplaza el instalador. Sí No
Archivos binarios dentro del paquete Sí No (externo)
Store elegible Sí (envío MSIX) Sí (envío MSI/EXE)
Identidad del paquete Sí Sí
Mecanismo de actualización Actualización de MSIX El mecanismo existente

Tutorial completo: Otorgar la identidad del paquete mediante el empaquetado con ubicación externa

Aplicaciones sin empaquetar

Las aplicaciones sin empaquetar no usan MSIX y no tienen identidad de paquete, lo que significa que no pueden acceder a las características enumeradas anteriormente.

  • Siguen completamente sin restricciones en términos de la superficie de la API, acceso al sistema de archivos, acceso al registro, elevación y modelo de proceso.
  • La instalación y las actualizaciones se basan en .exe, .msi, instaladores personalizados, ClickOnce o despliegue con xcopy.

Antes de decidirse por la opción sin empaquetar, compare la tabla de características anterior con su hoja de ruta. Si las notificaciones, las tareas en segundo plano o las API de IA están en el horizonte, considere adoptar un enfoque empaquetado.

Elección por escenario

Escenario Modelo recomendado Detalles
Desarrollador indie publicando en la Microsoft Store Paquete (MSIX) recomendado MSIX es la ruta de acceso recomendada: habilita las actualizaciones administradas por la Tienda, las descargas diferenciales y la desinstalación limpia. Las aplicaciones winUI 3 se empaquetan de forma predeterminada. La Tienda gestiona la firma de código de manera gratuita. → Distribuir la aplicación empaquetada

Las aplicaciones Win32 con un instalador MSI o EXE existente también pueden publicarse en la Tienda a través de la ruta de envío MSI/EXE, pero la Tienda no inserta actualizaciones para los usuarios existentes: la aplicación o el instalador deben controlar las actualizaciones.
Aplicación empresariales implementada a través de Intune o Administrador de configuración Empaquetado o ubicación externa para instaladores existentes Las nuevas aplicaciones deben usar MSIX. Las aplicaciones que ya existen y tienen su propio instalador pueden utilizar el empaquetado con una ubicación externa. Firma de código: utilice un certificado autofirmado (considerado de confianza a través de Intune, la Política de grupo o Administrador de configuración) o Azure Artifact Signing (anteriormente Trusted Signing). → Implementación de aplicaciones empaquetadas
ISV envía una descarga directa con su propio instalador Empaquetado con ubicación externa Registre un paquete de identidad ligero junto con el instalador existente. Firma de código: se requiere un certificado de confianza de una autoridad certificadora para la distribución fuera de la tienda. Azure Artifact Signing (anteriormente Trusted Signing) es la opción recomendada y más económica. → Asignar identidad del paquete

Como alternativa, envíe el instalador existente a la Tienda a través de la ruta de envío MSI/EXE.
Herramienta interna o utilidad de desarrollador Desempaquetado Más sencillo de compilar e implementar. El SDK de Aplicaciones para Windows funciona a través de NuGet, pero algunas características no estarán disponibles.

Sugerencia

¿No está seguro sobre los costos de firma de código? Publicar un paquete MSIX a través del Microsoft Store significa que no necesitas obtener ni administrar por separado un certificado para la confianza del usuario final, ya que Microsoft vuelve a firmar el paquete. La publicación de un instalador Win32 MSI/EXE a través del Store requiere un encadenamiento de certificados a una entidad de certificación en el Programa de Raíces de Confianza de Microsoft; no se acepta el certificado autofirmado. En el caso de otras rutas de distribución, el enfoque de firma depende del contexto de implementación: los entornos empresariales pueden confiar en un certificado autofirmado a través de la administración de dispositivos, mientras que la distribución no de la tienda normalmente requiere una solución de firma de código de confianza de CA. Azure Artifact Signing (antes Trusted Signing) es la opción recomendada por Microsoft (véase precios), y no requiere ningún token de hardware.

Despliegue dependiente del framework frente a despliegue autónomo

Independientemente del modelo de empaquetado, las aplicaciones que utilizan el SDK de aplicaciones de Windows eligen cómo administrar sus dependencias de tiempo de ejecución:

  • Dependiente del framework: el entorno de ejecución de SDK de Aplicaciones para Windows debe estar instalado en la máquina del usuario. Menor huella de la aplicación; depende de que el tiempo de ejecución esté presente o se instale automáticamente.
  • Self-contained: todos los archivos binarios de SDK de Aplicaciones para Windows se envían con la aplicación. Superficie mayor; ningún requisito de tiempo de ejecución externo. Adecuado para entornos empresariales bloqueados.

→ Implementación de aplicaciones independientes

Comienza con MSIX

Si compilas una aplicación de escritorio Win32 (a veces denominada clase aplicación de escritorio) o una aplicación de .NET , incluida Windows Presentation Foundation (WPF) y Windows Forms (WinForms), puedes empaquetar e implementar la aplicación mediante MSIX.

Migración a MSIX desde instaladores heredados

Si la aplicación usa actualmente un instalador heredado, puede migrar a MSIX para obtener una instalación o desinstalación limpia, actualizaciones automáticas, distribución de la Tienda e identidad de paquete. La ruta de migración depende de la tecnología del instalador actual y de si tiene acceso al código fuente.

Instalador actual Ruta de migración recomendada ¿Se requiere código fuente?
MSI (instalador de Windows) Use la herramienta de empaquetado MSIX para convertir msi directamente en MSIX. Controla la mayoría de los patrones MSI, incluidas las acciones personalizadas. No
ClickOnce (.NET) Recompile a partir del código fuente usando el proyecto de empaquetado MSIX de Visual Studio. La actualización automática de ClickOnce se puede reemplazar por las actualizaciones de la Tienda o el Instalador de aplicaciones. Sí
InstallShield/Instalador avanzado Use la herramienta MSIX Packaging Tool para capturar una instalación en una máquina virtual limpia. Es posible que las acciones personalizadas complejas necesiten correcciones manuales en el Editor de paquetes. No
Configuración de Inno/NSIS Use el flujo de trabajo de captura basado en máquinas virtuales de MSIX Packaging Tool. Ejecute el instalador EXE dentro del entorno limpio de la herramienta. No
App-V (paquetes virtuales) Conversión directamente mediante la herramienta de empaquetado MSIX: admite paquetes de App-V 5.x como entrada. No
MSIX con modificaciones necesarias Use el marco de soporte técnico de paquetes para aplicar correcciones en tiempo de ejecución (redirección de archivos o registros) sin cambiar el código de la aplicación. No

Sugerencia

Para las aplicaciones que tienen instaladores complejos con controladores de kernel, servicios que se ejecutan como SYSTEM o registros COM para todo el equipo que MSIX no admite, considere MSIX con ubicación externa (empaquetada con ubicación externa). Esto le proporciona la identidad del paquete para las características de Windows mientras usa un instalador tradicional para los componentes que requieren acceso elevado. Consulte Otorgar identidad al paquete mediante el empaquetado con una ubicación externa.

Consideraciones clave

  • Prueba en una máquina virtual limpia : la herramienta de empaquetado MSIX captura todos los cambios durante la instalación. Ejecútelo en una imagen de Windows limpia para evitar capturar cambios del sistema no relacionados.
  • Marco de compatibilidad de paquetes — Si la aplicación convertida tiene problemas de tiempo de ejecución (suposiciones sobre rutas de archivos, escrituras en el registro en HKLM), el Marco de compatibilidad de paquetes puede corregirlos sin modificar el código fuente.
  • En paralelo con el instalador heredado : puede implementar la versión MSIX junto con el instalador heredado durante la transición. Planee una configuración o migración de datos explícita (por ejemplo, importar en la primera ejecución) porque las ubicaciones de identidad y almacenamiento del paquete difieren entre las instalaciones MSIX y MSI/EXE.

Otras tecnologías de instalación

Contenido relacionado

  • Last updated on