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.
En este artículo se enumeran las cosas que debe saber antes de convertir el instalador existente en msix. Es posible que no tenga que hacer mucho para preparar la aplicación para el proceso de empaquetado, pero si alguno de los elementos siguientes se aplica a la aplicación, debe abordarlo antes de empaquetarlo.
La aplicación tiene un servicio. Se admite la conversión de aplicaciones con servicios, pero es importante tener en cuenta las limitaciones para convertir un servicio. Después de la conversión, necesitarás permisos de administrador para instalar el MSIX que incluye un servicio. Puedes convertir una aplicación con servicios a partir de la versión 1.2019.1220.0 de MSIX Packaging Tool y puedes implementar MSIX con servicios a partir de la versión de primavera de 2020 de Windows 10.
El instalador requiere un reinicio. Si el instalador requiere un reinicio, esta funcionalidad se admite en MSIX Packaging Tool comenzando con la versión 1.2019.701.0. Si el instalador devuelve un código de salida poco frecuente para indicar que necesita un reinicio, debe agregarlo a la sección de códigos de salida de reinicio de la configuración de msix Packaging Tool.
La aplicación .NET requiere una versión de .NET Framework anterior a la 4.6.2. Si va a empaquetar una aplicación .NET, se recomienda que la aplicación tenga como destino .NET Framework 4.6.2 o posterior. La capacidad de instalar y ejecutar aplicaciones de escritorio empaquetadas se introdujo por primera vez en Windows 10, versión 1607 (también denominada Actualización de aniversario), y esta versión del sistema operativo incluye .NET Framework 4.6.2 de forma predeterminada. Las versiones posteriores del sistema operativo incluyen versiones posteriores de .NET Framework. Para obtener una lista completa de las versiones de .NET incluidas en versiones posteriores de Windows 10, consulte este artículo.
Se espera que las versiones de destino de .NET Framework anteriores a la 4.6.2 de las aplicaciones de escritorio empaquetadas funcionen en la mayoría de los casos. Sin embargo, si tiene como destino una versión anterior a la 4.6.2, debe probar completamente la aplicación de escritorio empaquetada antes de distribuirla a los usuarios.
4.0 - 4.6.1: se espera que las aplicaciones destinadas a estas versiones de .NET Framework se ejecuten sin problemas en la versión 4.6.2 o posterior. Por lo tanto, estas aplicaciones deben instalar y ejecutarse sin cambios en Windows 10, versión 1607 o posterior con la versión de .NET Framework que se incluye con el sistema operativo.
2.0 y 3.5: en nuestras pruebas, las aplicaciones de escritorio empaquetadas destinadas a estas versiones de .NET Framework suelen funcionar, pero pueden presentar problemas de rendimiento en algunos escenarios. Para que estas aplicaciones empaquetadas se instalen y ejecuten, la característica de .NET Framework 3.5 debe instalarse en el equipo de destino (esta característica también incluye .NET Framework 2.0 y 3.0). También debe probar estas aplicaciones exhaustivamente después de empaquetarlas.
La aplicación requiere un controlador. MSIX no admite controladores.
La aplicación escribe en la carpeta AppData o en el Registro con la intención de compartir datos con otra aplicación. Después de la conversión, AppData se redirige al almacén de datos de la aplicación local, que es una tienda privada para cada aplicación.
Todas las entradas que escribe la aplicación en el subárbol del registro de HKEY_LOCAL_MACHINE se redirigen a un archivo binario aislado y las entradas que escribe la aplicación en el subárbol del registro de HKEY_CURRENT_USER se colocan en una ubicación privada por usuario y por aplicación. Para obtener más información sobre el redireccionamiento de archivos y registros, consulte Detrás de las escenas del Desktop Bridge.
La aplicación escribe en el directorio de instalación de la aplicación. Por ejemplo, la aplicación escribe en un archivo de registro que coloca en el mismo directorio que su exe. Esto no se admite porque la carpeta está protegida. Se recomienda escribir en otra ubicación, como el almacenamiento de datos local de la aplicación. Hemos agregado una funcionalidad que permite esto en 1809 y versiones posteriores.
La aplicación usa el directorio de trabajo actual. Durante la ejecución, la aplicación de escritorio empaquetada no obtendrá el mismo directorio de trabajo que había especificado anteriormente en el acceso directo .LNK del escritorio. Debe cambiar el CWD en tiempo de ejecución si tener el directorio correcto es importante para que la aplicación funcione correctamente.
La aplicación se instala y carga los ensamblados desde la carpeta de Windows en paralelo. Por ejemplo, la aplicación usa bibliotecas en tiempo de ejecución de C VC8 o VC9 y las vincula dinámicamente desde la carpeta en paralelo de Windows, lo que significa que el código usa los archivos DLL comunes de una carpeta compartida, como C:\Windows\WinSxS. Esto no se admite. Tendrá que vincularlos estáticamente mediante la vinculación a los archivos de biblioteca redistribuibles directamente en el código.
Otras consideraciones
Vuelva a empaquetar el instalador en la arquitectura adecuada. Si el instalador está pensado para instalarse en una máquina x86. Asegúrese de volver a empaquetar el instalador en una máquina x86. Esto es aplicable al instalador diseñado para máquinas x64.
Nota:
Si la aplicación necesita escribir en el directorio de instalación o usar el directorio de trabajo actual, también puede considerar la posibilidad de agregar una corrección en tiempo de ejecución mediante la Plataforma de compatibilidad de paquetes al paquete. Para más información, consulte este artículo.