Preparación del empaquetado de una aplicación de escritorio

En este artículo se enumeran los aspectos que debes tener en cuenta antes de empaquetar una aplicación de escritorio. Es posible que no tengas que hacer mucho para preparar la aplicación para el proceso de empaquetado, pero si alguno de los siguientes elementos se aplica a la aplicación, tendrás que abordarlo antes del empaquetado.

• La aplicación .NET requiere una versión del .NET Framework anterior a la 4.6.2. Si vas a empaquetar una aplicación .NET, se recomienda que la versión de destino de la aplicación sea .NET Framework 4.6.2 o versiones posteriores. La capacidad de instalar y ejecutar aplicaciones de escritorio empaquetadas se presentó 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 manera predeterminada. Las versiones posteriores del sistema operativo incluyen versiones posteriores de .NET Framework. Para obtener una lista completa de las versiones de .NET que se incluyen en las versiones posteriores de Windows 10, consulta este artículo.

  Se espera que las versiones de destino de .NET Framework anteriores a la 4.6.2 en aplicaciones de escritorio empaquetadas funcionen en la mayoría de los casos. Sin embargo, si la versión de destino es una versión anterior a la 4.6.2, deberás probar por completo la aplicación de escritorio empaquetada antes de distribuirla a los usuarios.

  • 4.0 a 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 en versiones posteriores. Por lo tanto, estas aplicaciones deben instalarse 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 generalmente funcionan, aunque pueden presentar problemas de rendimiento en algunos escenarios. Para que estas aplicaciones empaquetadas puedan instalarse y ejecutarse, se debe instalar la característica .NET Framework 3.5 en el equipo de destino (esta característica también incluye .NET Framework 2.0 y 3.0). También deberás probar estas aplicaciones minuciosamente después de empaquetarlas.

• La aplicación siempre se ejecuta con privilegios de seguridad elevados. La aplicación necesita funcionar mientras se ejecuta como el usuario interactivo. Los usuarios que instalen la aplicación pueden no ser administradores del sistema, por lo que exigir que la aplicación se ejecute con privilegios elevados significa que no se ejecutará correctamente para los usuarios estándar. Si planeas publicar la aplicación en Microsoft Store, las aplicaciones que requieran privilegios elevados para cualquier parte de su funcionalidad no se aceptarán en Store.

• La aplicación requiere un controlador de modo kernel o un servicio de Windows. MSIX no admite controladores en modo kernel o servicios de Windows que necesiten ejecutarse en una cuenta de sistema. En lugar de un servicio de Windows usa una tarea en segundo plano.

• Los módulos de la aplicación se cargan durante la operación a aquellos procesos que no están en el paquete de la aplicación de Windows. Esto no está permitido, lo que significa que las extensiones en proceso, como extensiones de shell, no se admiten. Pero si tienes dos aplicaciones en el mismo paquete, puedes realizar la comunicación entre procesos entre ellas.

• Asegúrate de que las extensiones instaladas por la aplicación se instalarán donde se instaló la aplicación. Windows permite a los usuarios y a los administradores de TI cambiar la ubicación de instalación predeterminada de los paquetes. Consulte "Configuración ->Sistema->Almacenamiento->Más configuraciones de almacenamiento-> Cambiar la ubicación de almacenamiento del contenido nuevo -> Las nuevas aplicaciones se guardarán en". Si vas a instalar una extensión con la aplicación, asegúrate de que la extensión no tiene restricciones adicionales con respecto a la carpeta de instalación. Por ejemplo, algunas extensiones pueden deshabilitar la instalación de su extensión en unidades que no son del sistema. Esto producirá un error 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) si se ha cambiado la ubicación predeterminada.

• La aplicación usa un identificador del modelo de usuario de la aplicación (AUMID) personalizado. Si el proceso llama a SetCurrentProcessExplicitAppUserModelID para establecer su propio AUMID, entonces solo puede usar el AUMID generado para este por el entorno del modelo de aplicaciones o el paquete de la aplicación de Windows. No se pueden definir AUMID personalizados.

• La aplicación modifica el subárbol del registro HKEY_LOCAL_MACHINE (HKLM) . Cualquier intento de tu aplicación para crear una clave HKLM o abrir una para realizar modificaciones producirá un error de acceso denegado. Recuerda que tu aplicación tiene su propia vista virtualizada privada del registro, por lo que no se aplica la noción de un subárbol del registro de nivel de usuario y de equipo (que es lo que HKLM es). Necesitas encontrar otra manera de lograr aquello para lo que usaste HKLM, como escribir en HKEY_CURRENT_USER (HKCU) en su lugar.

• La aplicación usa una subclave del registro ddeexec como un mecanismo para iniciar otra aplicación. En su lugar, usa uno de los controladores de verbo DelegateExecute como lo configuran las distintas extensiones activables* en tu manifiesto del paquete de la aplicación.

• 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 locales de la aplicación, que es un almacén privado para cada aplicación.

  Todas las entradas que tu aplicación escribe en el subárbol del registro HKEY_LOCAL_MACHINE se redirigen a un archivo binario aislado y las entradas que tu aplicación escribe en el subárbol del registro HKEY_CURRENT_USER se colocan en una ubicación privada por usuario y por aplicación. Para obtener más información acerca de la redirección de archivos y del registro, consulta Segundo plano del puente de dispositivo de escritorio.

  Usa un medio diferente para compartir datos entre procesos. Para obtener más información, consulta Almacenar y recuperar la configuración y otros datos de aplicación.

• 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 se coloca en el mismo directorio que el archivo .exe. Esto no se admite, por lo que tendrás que buscar otra ubicación, como el almacén de datos locales de la aplicación.

• La aplicación usa el directorio de trabajo actual. En tiempo de ejecución, la aplicación de escritorio empaquetada no obtendrá el mismo directorio de trabajo que especificaste anteriormente en el acceso directo .LNK del escritorio. Debes cambiar tu CWD en tiempo de ejecución si tener el directorio correcto es importante para que tu aplicación funcione correctamente.

  Nota

  Si la aplicación necesita escribir en el directorio de instalación o usar el directorio de trabajo actual, también puedes considerar la posibilidad de agregar una corrección en tiempo de ejecución mediante la Plataforma de compatibilidad de paquetes al paquete. Para obtener más información, consulta este artículo.

• La instalación de la aplicación requiere la interacción del usuario. El instalador de la aplicación debe ser capaz de ejecutarse de forma silenciosa e instalar todos los requisitos previos que no estén activados de forma predeterminada en una imagen limpia del sistema operativo.

• La aplicación expone objetos COM. Los procesos y extensiones del paquete se pueden registrar y usar como servidores COM y OLE. Asimismo, ambos pueden estar tanto dentro como fuera del proceso (OOP). La actualización de creadores agrega la compatibilidad con Packaged COM, que proporciona la capacidad de registrar los servidores OOP COM y OLE que ahora están visibles fuera del paquete. Consulta Compatibilidad del servidor COM y del documento OLE con el Puente de dispositivo de escritorio.

  La compatibilidad con Packaged COM funciona con las API de COM existentes, pero no con aquellas extensiones de aplicación que dependen de la lectura directa del registro, ya que la ubicación de Packaged COM es privada.

• La aplicación expone ensamblados GAC para que los usen otros procesos. La aplicación no puede exponer ensamblados GAC para que los usen procesos originados desde archivos ejecutables externos en el paquete de la aplicación de Windows. Los procesos internos del paquete pueden registrar y usar ensamblados GAC del modo habitual, pero no serán visibles externamente. Esto significa que los escenarios de interoperabilidad como OLE no funcionarán si los invocan procesos externos.

• La aplicación está vinculando las bibliotecas en tiempo de ejecución de C (CRT) de forma no admitida. La biblioteca en tiempo de ejecución de Microsoft C/C++ ofrece rutinas de programación para el sistema operativo Microsoft Windows. Estas rutinas automatizan muchas tareas comunes de programación que no proporcionan los lenguajes C y C++. Si la aplicación usa la biblioteca en tiempo de ejecución de C o C++, debes asegurarte de que esté vinculada de manera admitida.

  Visual Studio 2017 admite tanto la vinculación dinámica y estática, para permitir que el código use los archivos DLL comunes, como la vinculación estática, para vincular la biblioteca directamente en el código a la versión actual de CRT. Si es posible, se recomienda que la aplicación use la vinculación dinámica con VS 2017.

  La compatibilidad en versiones anteriores de Visual Studio varía. Consulta la tabla siguiente para obtener más información:

  Versión de Visual Studio	Vinculación dinámica	Vinculación estática
  2005 (VC 8)	Incompatible	Compatible
  2008 (VC 9)	Incompatible	Compatible
  2010 (VC 10)	Compatible	Compatible
  2012 (VC 11)	Compatible	Incompatible
  2013 (VC 12)	Compatible	Incompatible
  2015 y 2017 (VC 14)	Compatible	Compatible

  Nota: En todos los casos, debes realizar la vinculación a la última versión de CRT disponible públicamente.

• La aplicación se instala y carga los ensamblados desde la carpeta de Windows en paralelo. Por ejemplo, la aplicación usa las bibliotecas en tiempo de ejecución de C VC8 o VC9 y las vincula de forma dinámica desde la carpeta de Windows en paralelo, lo que significa que el código usa los archivos DLL comunes de una carpeta compartida. Esto no se admite. Deberás vincularlas de forma estática mediante la vinculación a los archivos de biblioteca redistribuibles directamente en el código.

• La aplicación usa una dependencia en la carpeta System32/SysWOW64. Para que las DLL funcionen, debes incluirlas en la parte del sistema de archivos virtual del paquete de la aplicación de Windows. Esto garantiza que la aplicación se comporte como si las DLL se hubieran instalado en la carpeta System32/SysWOW64. En la raíz del paquete, crea una carpeta denominada VFS. Dentro de esa carpeta, crear una carpeta SystemX64 y otra SystemX86. A continuación, pon la versión de 32 bits de la DLL en la carpeta SystemX86 y coloca la versión de 64 bits en la carpeta SystemX64.

• La aplicación usa un paquete de marcos de VCLibs. Si vas a convertir una aplicación Win32 de C++, debes controlar la implementación del entorno de ejecución de Visual C++. Visual Studio 2019 y Windows SDK incluyen los paquetes de marcos más recientes para la versión 11.0, 12.0 y 14.0 del entorno de ejecución de Visual C++ en las siguientes carpetas:

  • Paquetes de marcos de VC 14.0: C:\Archivos de programa (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0

  • Paquetes de marcos de VC 12.0: C:\Archivos de programa (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0

  • Paquetes de marcos de VC 11.0: C:\Archivos de programa (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0

  Para usar uno de estos paquetes, debes hacer referencia al paquete como una dependencia en el manifiesto del paquete. Cuando los clientes instalen la versión comercial de la aplicación desde Microsoft Store, el paquete se instalará desde Store junto con la aplicación. Las dependencias no se instalarán si realizas una instalación de prueba de la aplicación. Para instalar las dependencias manualmente, debes instalar el paquete de marcos adecuado mediante el paquete .appx correspondiente para x86, x64 o ARM, que se encuentra en las carpetas de instalación mencionadas anteriormente.

  Para hacer referencia a un paquete de marcos del entorno de ejecución de Visual C++ en la aplicación:

  1. Ve a la carpeta de instalación del paquete de marcos indicada anteriormente para la versión del entorno de ejecución de Visual C++ que la aplicación utiliza.

  2. Abre el archivo SDKManifest.xml de esa carpeta, busca el atributo FrameworkIdentity-Debug o FrameworkIdentity-Retail (en función de si estás usando la versión de depuración o comercial del entorno de ejecución) y copia los valores Name y MinVersion de ese atributo. Por ejemplo, este es el atributo FrameworkIdentity-Retail para el paquete de marcos actual de VC 14.0.

     FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"
     

  3. En el manifiesto del paquete de la aplicación, agrega el siguiente elemento <PackageDependency> en el nodo <Dependencies>. Asegúrate de reemplazar los valores Name y MinVersion por los valores que copiaste en el paso anterior. En el siguiente ejemplo se especifica una dependencia para la versión actual del paquete de marcos de VC 14.0.

     <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
     

• La aplicación contiene una lista de accesos directos personalizada. Hay varios problemas y advertencias que se deben tener en cuenta al usar las listas de accesos directos.

  • La arquitectura de tu aplicación no coincide con el sistema operativo. Actualmente, las listas de accesos directos no funcionan correctamente si las arquitecturas de la aplicación y del sistema operativo no coinciden (por ejemplo, una aplicación x86 que se ejecuta en Windows x64). En este momento, no existe ninguna solución alternativa que no sea la de volver a compilar la aplicación con la arquitectura coincidente.

  • La aplicación crea entradas de lista de accesos directos y llama a ICustomDestinationList::SetAppID o SetCurrentProcessExplicitAppUserModelID . No establezcas mediante programación el AppID en el código. Si lo haces, hará que las entradas de la lista de accesos directos no aparezcan. Si la aplicación necesita un identificador personalizado, especifícalo mediante el archivo de manifiesto. Consulta Empaquetado manual de una aplicación de escritorio para obtener instrucciones. El AppID de la aplicación se especifica en la sección YOUR_PRAID_HERE.

  • La aplicación agrega un vínculo de shell de lista de accesos directos que hace referencia a un ejecutable del paquete. No puedes iniciar ejecutables directamente en el paquete de una lista de accesos directos (a excepción de la ruta de acceso absoluta del propio .exe de una aplicación). En su lugar, registra un alias de ejecución de la aplicación (que permite que la aplicación de escritorio empaquetada se inicie a través de una palabra clave como si estuviera en PATH) y establece la ruta de acceso de destino del vínculo en el alias en su lugar. Para obtener más información sobre cómo usar la extensión appExecutionAlias, consulta Integración de aplicaciones de escritorio con Windows 10 . Ten en cuenta que si necesitas que los recursos del vínculo de la lista de accesos directos coincida con el .exe original, tendrás que establecer recursos como el icono con SetIconLocation y el nombre para mostrar con PKEY_Title igual que harías para otras entradas personalizadas.

  • La aplicación agrega entradas de lista de accesos directos que hacen referencia a recursos del paquete de la aplicación mediante rutas de acceso absolutas. La ruta de instalación de una aplicación puede cambiar cuando se actualizan sus paquetes, cambiando la ubicación de los recursos (como iconos, documentos, ejecutables, etcétera). Si las entradas de la lista de accesos directos hacen referencia a estos recursos mediante rutas de acceso absolutas, la aplicación debe actualizar periódicamente su lista de accesos directos (por ejemplo, al iniciar la aplicación) para garantizar que las rutas de acceso se resuelven correctamente. Como alternativa, usa las API Windows.UI.StartScreen.JumpList de UWP en su lugar, que permiten hacer referencia a los recursos de imagen y cadena con el esquema URI de ms-resource relativo del paquete (que también reconoce el idioma, PPP y contraste alto).

• La aplicación inicia una utilidad para realizar tareas. Evita iniciar utilidades de comando como PowerShell y Cmd.exe. De hecho, si los usuarios instalan la aplicación en un sistema que ejecuta Windows 10 S, la aplicación no podrá iniciar estas utilidades. Esto podría impedir que la aplicación se envíe a Microsoft Store, ya que todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con Windows 10 S.

  A menudo, iniciar una utilidad puede constituir una forma sencilla de conseguir información del sistema operativo, acceder al registro o acceder a las funcionalidades del sistema. Sin embargo, puedes usar las API de UWP para realizar este tipo de tareas en su lugar. Estas API son más eficaces porque no necesitan usar un archivo ejecutable independiente y, aún mejor, evitan que la aplicación salga del paquete. El diseño de la aplicación mantiene su coherencia gracias al aislamiento, confiabilidad y seguridad que proporciona una aplicación que ha empaquetado, por lo que la aplicación se comportará según lo esperado en aquellos sistemas que ejecuten Windows 10 S.

• La aplicación contiene complementos, módulos o extensiones. En muchos casos, las extensiones de estilo COM siguen funcionando siempre y cuando la extensión no se haya empaquetado y se instale como extensión de plena confianza. Esto es debido a que los instaladores pueden usar las funcionalidades de plena confianza para modificar el registro y colocar archivos de extensión donde se espera que la aplicación host los encuentre.

  Sin embargo, si las extensiones se empaquetan y se instalan como un paquete de aplicación de Windows, no funcionarán porque los paquetes (formados por la aplicación host y la extensión) estarán aislados entre sí. Para leer más acerca de cómo las aplicaciones se aíslan del sistema, consulta Segundo plano del puente de dispositivo de escritorio.

  Todas las aplicaciones y extensiones que instalen los usuarios en un sistema que ejecute Windows 10 S deben instalarse como paquetes de aplicación de Windows. Por lo tanto, si vas a empaquetar las extensiones o tienes previsto animar a tus colaboradores a empaquetarlas, ten en cuenta el modo de facilitar la comunicación entre el paquete de la aplicación host y los paquetes de la extensión. Una solución que puedes plantear es usar un servicio de aplicación.

• La aplicación genera código. La aplicación puede generar código que consume en la memoria, pero evita escribir código generado en el disco, debido a que el proceso de certificación de aplicaciones de Windows no puede validar el código antes de enviar la aplicación. Además, las aplicaciones que escriben código en el disco no se ejecutarán correctamente en sistemas que ejecutan Windows 10 S. Esto podría impedir que la aplicación se envíe a Microsoft Store, ya que todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con Windows 10 S.

Importante

Una vez que hayas creado el paquete de la aplicación de Windows, prueba tu aplicación para garantizar que funcione correctamente en sistemas que ejecutan Windows 10 S. Todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con aplicaciones de Windows 10 S. Las aplicaciones que no sean compatibles no se aceptarán en Microsoft Store. Consulta Probar la aplicación de Windows en Windows 10 S.