Skip to main content
Muchos juegos usan software antitrampas y otro middleware. Estos componentes se suelen instalar en cadena cuando el usuario instala el juego. Un usuario puede instalar un juego a través de Microsoft Store y otro juego a través de algún otro canal de distribución. La plataforma garantiza que no haya conflictos si ambos juegos instalan en cadena el mismo paquete de middleware. El juego puede incluir en su paquete uno o varios archivos .exe o .msi arbitrarios y solicitar que estos archivos se ejecuten como parte de la finalización de la instalación de la aplicación. La característica de acciones de instalación personalizadas está pensada para instalar software antitrampas de juegos o algún otro middleware redistribuible. De esta manera, puede usar exactamente el mismo archivo .exe de instalación en cadena en un MSIX enviado a Microsoft Store, así como en un archivo .msi o .exe enviado a través de algún otro canal de distribución. En las aplicaciones Win32 tradicionales, el middleware compartido se suele instalar mediante archivos redistribuibles independientes, que normalmente adoptan la forma de un .exe autoextraíble o de un .msi que se puede empaquetar con el propio juego. Las aplicaciones de Microsoft Store modelan las dependencias como paquetes de marco que no se empaquetan con el juego, sino que se implementan por separado a través de Microsoft Store. En este modelo, el manifiesto de la aplicación consumidora declara una dependencia de uno o varios paquetes de marco. Microsoft Store se encarga entonces de encadenar la instalación de las dependencias. Aunque muchos redistribuibles están disponibles como paquetes de marco en Microsoft Store, inevitablemente habrá algunos redistribuibles que no estén disponibles como paquetes de marco. Para estos paquetes, la solución es permitir que el juego incluya el redistribuible dentro del paquete del juego. Para incluir redistribuibles .exe o .msi, debe realizar actualizaciones en el archivo MicrosoftGame.config. Estos cambios incluyen declarar el tipo de acción personalizada que quiere usar, así como su ubicación dentro del paquete de instalación. Todos los redistribuibles deben incluirse en el paquete y declararse en MicrosoftGame.config. La declaración incluye la ruta al ejecutable (relativa a la ruta de Folder declarada, que a su vez es relativa a la ruta raíz del propio paquete). La declaración también incluye los argumentos de línea de comandos que se pasarán al ejecutable cuando se ejecute. Esto se hace mediante la inclusión del elemento CustomInstallActions en el archivo MicrosoftGame.config.

​
CustomInstallActions

El elemento CustomInstallActions contiene todas las definiciones de qué acciones de instalación personalizadas se deben ejecutar y cuándo deben ejecutarse. Solo puede declarar una instancia de este elemento en su archivo MicrosoftGame.config. Tiene un elemento secundario obligatorio, Folder, que es una cadena que designa la carpeta que contiene todos los archivos necesarios para todas las acciones personalizadas. Esta carpeta puede contener subcarpetas. Usted es responsable de garantizar que el paquete incluya las dependencias de los ejecutables de las acciones personalizadas, y de que estas se encuentren en la ruta de carga adecuada para cada uno.
Al empaquetar el título, makepkg traduce este elemento CustomInstallActions a la extensión MSIX windows.customInstall en el appxmanifest.xml generado, donde el elemento equivalente es <CustomInstall> con Folder expresado como un atributo. Usted no crea esa forma <CustomInstall> por sí mismo: en MicrosoftGame.config, Folder es un elemento secundario de CustomInstallActions, como se muestra en los ejemplos de Cambios en el archivo de configuración del juego más adelante en este artículo.
No debe colocar ninguno de los ejecutables principales del juego ni otros archivos en la carpeta Folder designada. Es explícitamente solo para archivos de instalación personalizada.
Dentro del elemento CustomInstallActions, la aplicación puede declarar los elementos secundarios InstallActionList, RepairActionList y UninstallActionList. Todos son opcionales: puede declarar cualquiera de ellos o ninguno. Dentro de cada una de estas listas, se especifican uno o varios elementos secundarios InstallAction, RepairAction o UninstallAction. La plataforma ejecuta las acciones que especifique en el orden que especifique, con los argumentos de línea de comandos que especifique.

​
Tipos de acciones

Los tres nodos secundarios de la extensión de instalación personalizada determinan cuándo se ejecutan determinadas acciones personalizadas. Hay tres tipos de acciones de instalación personalizadas.
  • Acción de instalación: acciones que la plataforma ejecuta antes del primer inicio de la aplicación
  • Acción de reparación: acciones que se ejecutan cuando el usuario selecciona Reparar o Restablecer
  • Acción de desinstalación: acciones que se ejecutan cuando el usuario desinstala la aplicación
A pesar del nombre, una acción de instalación no se ejecuta cuando se instala el paquete. Cada tipo de acción se ejecuta en un punto específico del ciclo de vida de la aplicación, y una InstallAction se ejecuta una vez, inmediatamente antes del primer inicio del título (este es el primer punto en el que la plataforma puede mostrar el aviso de UAC requerido). “Install”, “Repair” y “Uninstall” nombran la categoría del ciclo de vida a la que pertenece la acción, no el momento en que se ejecuta. Si necesita realizar trabajo en el momento real de la instalación o descarga del paquete, las acciones de instalación personalizadas no son el mecanismo. Consulte Uso de las acciones personalizadas para conocer la secuencia completa.
Normalmente, se especificaría la instalación en cadena de algún redistribuible como una InstallAction y, a continuación, se especificaría su desinstalación como una UninstallAction. Sin embargo, en algunos casos podría optar por instalar sin una desinstalación correspondiente. En este escenario, la aplicación instala algo que deja atrás cuando se desinstala, lo que podría ser adecuado para redistribuibles compartidos por otras aplicaciones. De forma similar, su RepairAction podría ser simplemente una redeclaración de los ejecutables que especificó para su InstallAction, y esto es lo habitual. Es posible que cada una de las acciones que quiere realizar en instalación/reparación/desinstalación requiera un ejecutable diferente. El esquema es muy flexible: la plataforma no exige ninguna de las acciones. Puede configurar los comportamientos según corresponda para cada juego.
La acción de desinstalación solo se ejecutará si se ha ejecutado una acción de instalación o de reparación. El sistema usa la propiedad Name para hacer un seguimiento de este estado. Por este motivo, es importante que las acciones de instalación/reparación/desinstalación tengan el mismo Name.

​
Partes de una acción

​
File

Para cada acción, debe especificar el archivo que se va a ejecutar, y este archivo debe estar en el paquete. Si especifica una ruta, será implícitamente relativa a la ruta de Folder de CustomInstallActions. No puede especificar una ruta absoluta. La ruta no debe comenzar con una barra diagonal inversa (\).

​
Name

Debe especificar un Name para la acción. Este Name debe ser único dentro del nodo Actions primario, pero puede compartirse entre distintos nodos Actions. Por ejemplo, podría especificar File=“MySetup.exe” y Name=“abc123” tanto como InstallAction como RepairAction. Por otro lado, si tiene dos elementos InstallAction, cada uno debe tener un Name diferente. Debe usar el mismo Name para el mismo ejecutable en las distintas versiones del paquete, siempre que ese ejecutable no cambie. El Name se usa como identidad de la acción y permite a la plataforma hacer un seguimiento de qué acciones se han ejecutado correctamente y de si deben ejecutarse para un paquete actualizado. Si un paquete actualizado especifica una acción personalizada con un Name que ya se ha ejecutado correctamente, la plataforma omite esta acción durante la actualización.
Una diferencia en la lista de argumentos no constituye una diferencia de identidad. Si quiere ejecutar el mismo ejecutable con argumentos diferentes en un paquete actualizado, debe proporcionar un Name diferente. Es su responsabilidad configurar los Names declarados adecuadamente y hacer un seguimiento de ellos entre versiones.

​
Arguments

Cada acción de instalación personalizada tiene un tercer elemento, argument, que permite incluir los argumentos que necesite para ejecutar el comando del redistribuible.

​
Uso de las acciones personalizadas

La instalación de software antitrampas suele requerir que el usuario tenga privilegios de administrador y, en general, dado que las acciones personalizadas son una característica extremadamente potente, la plataforma requiere privilegios de administrador para cualquier paquete que tenga acciones personalizadas. Para las operaciones que se ejecutan con privilegios de administrador, Windows requiere que se muestre un aviso de Control de cuentas de usuario (UAC) en la primera ejecución de la aplicación. El flujo de trabajo del usuario es el siguiente.
  • La página de Microsoft Store del juego incluye una descripción de los requisitos, incluidos si la instalación requiere privilegios elevados, si la instalación ejecuta una acción personalizada y lo que esto podría significar para el usuario. Esta información se proporciona para que el usuario pueda tomar una decisión informada sobre la compra del juego.
  • Suponiendo que el usuario esté conforme con las restricciones e implicaciones, selecciona Instalar.
  • La plataforma detecta que el paquete incluye una acción personalizada y registra el hecho de que la acción personalizada debe ejecutarse. Sin embargo, no ejecuta la acción personalizada durante la fase de instalación inicial. En su lugar, cualquier acción personalizada se ejecuta la primera vez que el usuario inicia el juego.
  • En el primer inicio del juego, en el punto en que la plataforma está a punto de ejecutar las acciones personalizadas, muestra un aviso de UAC. El usuario debe entonces proporcionar credenciales de administrador y aceptar la elevación. Incluso si un paquete contiene varias acciones personalizadas, el usuario solo recibe un aviso de UAC. No hay más avisos de UAC para las actualizaciones, a menos que una o varias de las acciones personalizadas hayan cambiado. Hay un aviso de UAC cuando se desinstala el juego.
Todas las acciones personalizadas deben devolver cero para indicar éxito. Si alguna acción personalizada falla, la plataforma continúa ejecutando las acciones personalizadas restantes y continúa intentando iniciar la aplicación. En cada inicio posterior de la aplicación, la plataforma sigue reintentando cualquier acción personalizada de instalación fallida o incompleta hasta que esa acción se complete correctamente. Si la aplicación no funciona correctamente ante un error de una acción personalizada, el usuario siempre puede ir a la página de configuración de la aplicación y seleccionar Reparar o Restablecer. Una reparación o un restablecimiento no vuelve a descargar los archivos del juego: simplemente vuelve a registrar el paquete. Todas las acciones personalizadas fallidas o no ejecutadas se vuelven a registrar para su ejecución. Si tiene un instalador personalizado que devuelve algún valor distinto de cero para indicar éxito, una opción es encapsular este instalador en otro ejecutable que usted cree, que sí devuelva cero cuando se complete correctamente. La directiva de Microsoft Store incluye directrices sobre qué tipos de software middleware/redistribuible se permite instalar en cadena. A grandes rasgos, las instalaciones en cadena están pensadas para software compartido que es necesario para ejecutar el juego. No están pensadas para instalar aplicaciones no relacionadas u otro software.
Las acciones de instalación personalizadas solo se admiten dentro del paquete MSIXVC principal. No se admiten en paquetes de marco, paquetes opcionales, paquetes de modificación ni en ningún otro tipo de paquete.
Las acciones personalizadas de instalación, reparación y desinstalación las ejecuta la canalización de implementación comercial de Microsoft Store. No se ejecutan cuando instala el paquete localmente para desarrollo, por ejemplo, cuando instala un .msixvc suelto mediante wdApp install o registra un paquete mediante Add-AppxPackage. Una instalación local de desarrollo aún le permite comprobar que su paquete declara las acciones correctamente (aparecen en el appxmanifest.xml generado como la extensión windows.customInstall), pero los propios ejecutables de las acciones personalizadas no se invocan en esa ruta. Para validar las acciones ejecutándose de un extremo a otro, instale el título a través de un flujo de Store o de sandbox.

​
Ejecución de un MSI como acción de instalación personalizada

En el caso de un MSI, usted proporciona el nombre del MSI y la plataforma ejecuta msiexec.exe sobre ese archivo. No proporcione los argumentos /i, /f ni /x, porque se infieren del tipo de la acción (instalación, reparación o desinstalación) donde se declara. No puede proporcionar ninguna opción al modificador /f. Sin embargo, puede proporcionar cualquier otro argumento opcional que normalmente se proporcionaría a msiexec.exe. Este es el único escenario en el que los argumentos de línea de comandos están restringidos: para las acciones que no son MSI, puede proporcionar los argumentos que quiera. Para las acciones que no son MSI, la plataforma no analiza ni valida los argumentos. La plataforma simplemente los pasa al ejecutable. Es su responsabilidad garantizar que los argumentos sean correctos. No hay compatibilidad directa con MST (transformaciones de MSI). Si tiene un requisito de MSI/MST, una posible solución alternativa podría ser crear un .exe independiente que encapsule msiexec para ejecutar su MSI y aplicar su MST.

​
Cambios en el archivo de configuración del juego

Los siguientes ejemplos XML muestran las adiciones adecuadas a un archivo MicrosoftGame.config para permitir acciones de instalación personalizadas.
En el ejemplo anterior, todos los ejecutables y sus dependencias deben colocarse en la carpeta MyInstallers que especificó en la raíz del paquete. Dentro de esa carpeta, puede crear cualquier estructura de subcarpetas adecuada para su aplicación. En este ejemplo, la ruta a MySetup.exe sería <raíz del paquete>\MyInstallers\Banana\MySetup.exe. Si ese ejecutable tiene dependencias, también deben colocarse en la carpeta o subcarpeta adecuada. La siguiente secuencia muestra cómo se crearía el manifiesto a lo largo de varias versiones.
Última modificación el 28 de agosto de 2026

Temas relacionados

Introducción al empaquetado de títulos para PC con las herramientas MSIXVCDependencias de paquetes de plataforma (framework)GameInput para PC y consola con NuGetEmpaquetado e implementación para títulos de XBOX con el GDKSegmentación avanzada con propiedades personalizadas de jugador