Preparación para empaquetar una aplicación de escritorio

En este artículo se enumeran las cosas que debe saber antes de empaquetar la aplicación de escritorio. 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 .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 siempre se ejecuta con privilegios de seguridad elevados. La aplicación debe funcionar mientras se ejecuta como usuario interactivo. Es posible que los usuarios que instalen la aplicación no sean administradores del sistema, por lo que requerir que la aplicación se ejecute con privilegios elevados significa que no se ejecutará correctamente para los usuarios estándar. Si planea publicar la aplicación en Microsoft Store, las aplicaciones que requieren elevación para cualquier parte de su funcionalidad no se aceptarán en la Tienda.

• La aplicación requiere un controlador de Windows. MSIX no admite controladores de Windows.

• La aplicación requiere un servicio de Windows de usuario. MSIX no admite servicios de Windows por usuario. MSIX admite servicios de sesión 0 (por máquina) que se ejecutan en una de las cuentas de sistema definidas (LocalSystem, LocalService o NetworkService). En lugar de un servicio de Windows de usuario, use 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 se permite, lo que significa que no se admiten extensiones en proceso, como extensiones de shell. Pero si tiene dos aplicaciones en el mismo paquete, puede realizar la comunicación entre procesos entre ellas.

• Asegúrese de que las extensiones instaladas por la aplicación instalarán dónde está instalada la aplicación. Windows permite a los usuarios y administradores de TI cambiar la ubicación de instalación predeterminada para los paquetes. Consulte "Configuración->Sistema->Almacenamiento->Más configuraciones de almacenamiento-> Cambiar dónde se guarda el nuevo contenido-> Las nuevas aplicaciones se guardarán en". Si va a instalar una extensión con la aplicación, asegúrese de que la extensión no tiene restricciones adicionales de 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 de modelo de usuario de aplicación (AUMID) personalizado. Si el proceso llama a SetCurrentProcessExplicitAppUserModelID para establecer su propio AUMID, solo puede usar el AUMID generado para él por el entorno del modelo de aplicación o el paquete de aplicación de Windows. No se pueden definir AUMIDs personalizados.

• La aplicación modifica el subárbol del registro HKEY_LOCAL_MACHINE (HKLM). Cualquier intento de la aplicación de crear una clave HKLM o abrir una para su modificación producirá un error de acceso denegado. Recuerde que la 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 que abarque tanto al usuario como a la máquina (HKLM). Necesita encontrar otra manera de lograr aquello para lo que estaba usando HKLM, como escribir en HKEY_CURRENT_USER (HKCU) en su lugar.

• La aplicación usa una subclave del Registro ddeexec como medio para iniciar otra aplicación. En su lugar, use uno de los controladores de verbo DelegateExecute como lo configuran las distintas extensiones activables* en su manifiesto de 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 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.

  Use un medio diferente de uso compartido de datos entre procesos. Para obtener más información, consulte 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 coloca en el mismo directorio que su exe. Esto no se admite, por lo que deberá encontrar otra ubicación, como el almacén de datos de la aplicación local.

• 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.

  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.

• La instalación de la aplicación requiere interacción del usuario. El instalador de la aplicación debe poder ejecutarse de forma silenciosa y debe instalar todos sus 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 desde dentro del paquete pueden registrar y usar servidores COM y OLE, tanto en proceso como fuera de 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 los procesos que se originan en ejecutables externos al paquete de la aplicación de Windows. Los procesos dentro del paquete pueden registrar y usar ensamblados GAC de forma habitual, pero no serán visibles externamente. Esto significa que los escenarios de interoperabilidad, como OLE, no funcionarán si son invocados por procesos externos.

• La aplicación está vinculando bibliotecas en tiempo de ejecución de C (CRT) de forma no admitida. La biblioteca en tiempo de ejecución de Microsoft C/C++ proporciona rutinas para programar el sistema operativo Microsoft Windows. Estas rutinas automatizan muchas tareas de programación comunes que no proporcionan los lenguajes C y C++. Si la aplicación usa la biblioteca en tiempo de ejecución de C/C++, debe asegurarse de que está vinculada de forma compatible.

  Visual Studio 2017 admite la vinculación dinámica y estática, para permitir que el código use los archivos DLL comunes o 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 con versiones anteriores de Visual Studio varía. Consulte la tabla siguiente para más detalles:

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

  Nota: En todos los casos, debe vincular a la versión más reciente 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 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. Esto no se admite. Tendrá que vincularlos estáticamente 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 estos archivos DLL funcionen, debe incluirlos 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 los archivos DLL se instalaran en la carpeta System32/SysWOW64 . En la raíz del paquete, cree una carpeta denominada VFS. Dentro de esa carpeta, cree una carpeta SystemX64 y SystemX86 . A continuación, coloque la versión de 32 bits del archivo DLL en la carpeta SystemX86 y coloque la versión de 64 bits en la carpeta SystemX64 .

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

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

  • Paquetes de marco 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, debe hacer referencia al paquete como una dependencia en el manifiesto del paquete. Cuando los clientes instalan la versión comercial de la aplicación desde Microsoft Store, el paquete se instalará desde la Tienda junto con la aplicación. Las dependencias no se instalarán si carga su aplicación de forma lateral. Para instalar las dependencias manualmente, debe instalar el paquete de marco adecuado mediante el paquete de .appx adecuado para x86, x64 o ARM ubicado en las carpetas de instalación enumeradas anteriormente.

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

  1. Vaya a la carpeta de instalación del paquete de marco que se muestra anteriormente para la versión del runtime de Visual C++ que usa la aplicación.

  2. Abra el archivo SDKManifest.xml en esa carpeta, localice el atributo FrameworkIdentity-Debug o FrameworkIdentity-Retail (dependiendo de si está usando la versión de depuración o comercial del entorno de ejecución), y copie los valores Name y MinVersion de ese atributo. Por ejemplo, este es el atributo FrameworkIdentity-Retail para el paquete actual del marco de trabajo 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, agregue el elemento <PackageDependency> debajo del nodo <Dependencies>. Asegúrese de reemplazar los Name valores y MinVersion por los valores que copió en el paso anterior. En el ejemplo siguiente se especifica una dependencia para la versión actual del paquete de marco 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 saltos personalizada. Hay varios problemas y advertencias que se deben tener en cuenta al usar las listas de accesos directos.

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

  • La aplicación crea entradas de lista de accesos directos y llama a ICustomDestinationList::SetAppID o SetCurrentProcessExplicitAppUserModelID. No establezca el AppID mediante programación en el código. Si lo hace, las entradas de la lista de accesos directos no aparecerán. Si la aplicación necesita un identificador personalizado, especifíquelo mediante el archivo de manifiesto. Consulte Empaquetar manualmente una aplicación de escritorio para obtener instrucciones. El ID de aplicación para su aplicación está especificado 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 se pueden iniciar archivos ejecutables directamente en el paquete desde una lista de accesos directos (con la excepción de la ruta de acceso absoluta del propio .exe de una aplicación). En su lugar, registre 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 el PATH) y establezca la ruta de destino del enlace en el alias. Para obtener más información sobre cómo usar la extensión appExecutionAlias, consulta Integrar la aplicación de escritorio con Windows 10. Tenga en cuenta que si necesita recursos del vínculo en la lista de accesos directos para que coincidan con el .exe original, deberá establecer recursos como el icono mediante SetIconLocation y el nombre para mostrar con PKEY_Title como lo haría 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.). Si las entradas de la lista de accesos directos hacen referencia a estos recursos por rutas de acceso absolutas, la aplicación debe actualizar su lista de accesos directos periódicamente (por ejemplo, en el inicio de la aplicación) para asegurarse de que las rutas de acceso se resuelvan correctamente. Como alternativa, use 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. Evite iniciar utilidades de comandos 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á iniciarla en absoluto. Esto podría impedir que la aplicación se envíe a Microsoft Store porque todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con Windows 10 S.

  A menudo, iniciar una utilidad puede proporcionar una manera cómoda de obtener 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. Esas API son más eficaces porque no necesitan un archivo ejecutable independiente para ejecutarse, pero lo más importante es que impiden que la aplicación llegue fuera del paquete. El diseño de la aplicación sigue siendo coherente con el aislamiento, la confianza y la seguridad que viene con una aplicación empaquetada y la aplicación se comportará según lo previsto en los sistemas que ejecutan Windows 10 S.

• Su aplicación hospeda añadidos, complementos 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 se debe a que esos instaladores pueden usar sus funcionalidades de plena confianza para modificar el registro y colocar archivos de extensión dondequiera que la aplicación host espera encontrarlos.

  Sin embargo, si esas extensiones se empaquetan y, a continuación, se instalan como un paquete de aplicación de Windows, no funcionarán porque cada paquete (la aplicación host y la extensión) se aislarán entre sí. Para obtener más información sobre cómo las aplicaciones están aisladas del sistema, consulte Detrás de las escenas del Desktop Bridge.

  Todas las aplicaciones y extensiones que los usuarios instalan en un sistema que ejecuta Windows 10 S deben instalarse como paquetes de aplicaciones de Windows. Por lo tanto, si piensa empaquetar las extensiones o planea animar a los colaboradores a empaquetarlos, considere cómo puede facilitar la comunicación entre el paquete de aplicación host y los paquetes de extensión. Una manera de hacerlo es usar un servicio de aplicaciones.

• La aplicación genera código. La aplicación puede generar código que consume en memoria, pero evitar escribir código generado en disco porque el proceso de certificación de aplicaciones de Windows no puede validar ese código antes del envío de la aplicación. Además, las aplicaciones que escriben código en 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 porque todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con Windows 10 S.

Importante

Después de crear el paquete de la aplicación de Windows, pruebe la aplicación para asegurarse de que funciona correctamente en sistemas que ejecutan Windows 10 S. Todas las aplicaciones enviadas a Microsoft Store deben ser compatibles con Windows 10 S. Las aplicaciones que no son compatibles no se aceptarán en la tienda. Consulta Prueba tu aplicación de Windows para Windows 10 S.