Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Un proyecto de SDK de Aplicaciones para Windows depende del marco de forma predeterminada. Para cambiar al despliegue autónomo, siga los pasos que se indican a continuación (los términos dependiente del marco y autocontenido se describen en Descripción general de la implementación del SDK de Windows App).
- En Visual Studio, haga clic con el botón derecho en el nodo del proyecto de aplicación y haga clic en Editar archivo de proyecto para abrir el archivo de proyecto de aplicación para su edición. Para un proyecto C++, primero haga clic en Descargar proyecto.
- En el archivo de proyecto de la app, dentro del principal
PropertyGroup, añada<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>como se muestra en la captura de pantalla siguiente.
- Guarde y cierre el archivo del proyecto.
- Haga clic en Volver a cargar proyecto.
- Si utiliza un proyecto de empaquetado de aplicaciones de Windows (en lugar del MSIX de un solo proyecto que se obtiene con WinUI Blank App (Packaged)), realice también todos los cambios anteriores en el archivo de proyecto del proyecto de empaquetado.
Nota:
No se deben cambiar los proyectos de biblioteca. La implementación independiente solo debe configurarse en proyectos de aplicación (y, si procede, en un proyecto de empaquetado de aplicaciones de Windows).
Para aplicaciones de ejemplo, consulte ejemplos de implementación autónoma del SDK de aplicaciones de Windows.
Una vez que se haya establecido la propiedad WindowsAppSDKSelfContained en true en el archivo de proyecto, el contenido del paquete de SDK de Aplicaciones para Windows Framework se extraerá a la salida de la compilación y se implementará como parte de tu aplicación.
Nota:
Las aplicaciones .NET también deben publicarse como autocontenidas para ser totalmente autocontenidas. Consulte este ejemplo para saber cómo configurar .NET autocontenido con perfiles de publicación.
Tenga en cuenta que dotnet publish agrupa ensamblados administrados, pero no puede generar un EXE de un solo archivo para aplicaciones WinUI 3: las dependencias nativas del entorno de ejecución de SDK de Aplicaciones para Windows deben permanecer como archivos independientes. Consulte EXE de un solo archivo para obtener más información.
Nota:
Las aplicaciones de C++ también deben utilizar el CRT híbrido para ser totalmente independientes. La importación de HybridCRT.props desde Directory.Build.props es la manera recomendada de configurarla para todos los proyectos de una solución (vea un ejemplo en Directory.Build.props). Una aplicación empaquetada también debe establecer <UseCrtSDKReferenceStaticWarning>false</UseCrtSDKReferenceStaticWarning> en su archivo de proyecto. Consulte la aplicación de ejemplo Implementación autónoma para ver cómo utilizar la CRT híbrida.
Si su aplicación está empaquetada (para obtener más información, consulte Información general del empaquetado y la implementación), las dependencias del SDK de aplicaciones de Windows se incluirán como contenido dentro del paquete MSIX. La implementación de la aplicación todavía requiere registrar el paquete MSIX como cualquier otra aplicación empaquetada.
Si su aplicación está empaquetada con ubicación externa o sin empaquetar, las dependencias del SDK de aplicaciones de Windows se copian junto a .exe en la salida de la compilación. Puede implementar los archivos resultantes mediante xcopy o incluirlos en un instalador personalizado.
Dependencias de paquetes MSIX adicionales
Un pequeño número de API del SDK de aplicaciones de Windows se basa en paquetes MSIX adicionales que representan la funcionalidad crítica del sistema operativo (SO).
- Por ejemplo, las API de notificación push (PushNotificationManager) tienen una dependencia en el paquete Singleton (las API de notificación de aplicaciones, como AppNotificationManager , no requieren este paquete). Consulte Arquitectura de implementación para la SDK de Aplicaciones para Windows.
Para usar las API que dependen de paquetes MSIX adicionales en una aplicación independiente, tiene las siguientes opciones:
- Puede hacer que la funcionalidad sea opcional y encenderla solo si es posible y siempre que sea posible. Llamar al método IsSupported de las API (PushNotificationManager.IsSupported) le permitirá comprobar dinámicamente en tiempo de ejecución si las API están disponibles para la aplicación que realiza la llamada en el sistema en el que se ejecuta.
- Esto permite el uso seguro, condicional y opcional de las API sin poner en peligro la simplicidad de la implementación independiente.
- Solo si los servicios del sistema operativo están instalados fuera de la implementación de la aplicación, la aplicación activará la funcionalidad adecuada. Pero de hecho hay algunos casos en los que las API funcionarán incluso sin que el paquete Singleton esté presente; por lo tanto, llamar a IsSupported para comprobar a menudo es una buena idea.
- Implemente los paquetes MSIX necesarios como parte de la instalación de la aplicación.
- Esto le permite depender de la API en todos los escenarios. Pero requerir la implementación de paquetes MSIX de dependencias como parte de la implementación de su app puede comprometer la simplicidad de la implementación autocontenida.
- No use la API.
- Considere las API alternativas que proporcionan una funcionalidad similar sin requisitos de implementación adicionales.
Optar por no participar (o participar) en la compatibilidad automática con UndockedRegFreeWinRT
La propiedad del proyecto WindowsAppSdkUndockedRegFreeWinRTInitialize controla si la implementación del SDK de aplicaciones de Windows Runtime sin registro y desacoplado (UndockedRegFreeWinRT) se habilita automáticamente al iniciar la aplicación. Esa compatibilidad es necesaria para aplicaciones independientes desempaquetadas.
WindowsAppSdkUndockedRegFreeWinRTInitialize tiene como valor true si WindowsAppSDKSelfContained es true y WindowsPackageType es None y la propiedad del proyecto OutputType se establece en Exe o WinExe (es decir, el proyecto genera un ejecutable). Esa última condición impide agregar compatibilidad automática de UndockedRegFreeWinRT en archivos DLL de biblioteca de clases y otros archivos no ejecutables de forma predeterminada. Si necesita compatibilidad automática con UndockedRegFreeWinRT en un archivo no ejecutable (por ejemplo, un archivo DLL de prueba cargado por un ejecutable de proceso de host que no inicializa UndockedRegFreeWinRT), puede habilitarlo explícitamente en el proyecto con <WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize>.