Convertir un EXE a MSIX es sencillo cuando el instalador se porta bien y genuinamente difícil cuando no. La mayoría de las guías cubren el primer caso. Esta cubre el camino entero, incluidas las partes donde sale mal, porque ahí es donde se va el tiempo de verdad.
El estado final es un paquete MSIX firmado que se instala limpiamente, se desinstala limpiamente y se despliega a través de Intune.
Antes de empezar: ¿es MSIX el objetivo correcto?
Merece treinta segundos, porque ahorra días.
MSIX encaja con aplicaciones de escritorio corrientes en modo usuario. No encaja con nada que instale un controlador, registre un servicio del sistema, necesite escribir en ubicaciones a nivel de máquina que otras aplicaciones leen, o se enganche profundamente al sistema operativo. Si su EXE hace alguna de esas cosas, empaquétela como MSI o a través del PowerShell App Deployment Toolkit en su lugar y siga adelante. Forzarla dentro de MSIX produce un paquete que técnicamente existe y nunca acaba de funcionar.
Tres preguntas resuelven la mayoría de los casos antes de que abra ninguna herramienta:
- ¿Necesita el instalador derechos administrativos para algo más allá de escribir en Program Files? Escribir en Program Files es normal. Instalar un servicio, un controlador o un enganche a nivel de sistema es la señal para parar.
- ¿Lee alguna otra cosa lo que esta aplicación escribe? MSIX redirige las escrituras a un contenedor por usuario, así que si otra aplicación, una tarea programada o un agente de supervisión lee un archivo o una clave que esta produce, la redirección hace esos datos invisibles para ellos. Eso parece un paquete funcionando y no lo es.
- ¿El fabricante ya distribuye un MSIX? Pregunte antes de capturar. Reempaquetar un instalador que tiene un MSIX soportado es trabajo que sencillamente puede no hacer.
Si no está seguro, ejecute la conversión de todos modos pero póngale un límite de tiempo. El fallo será evidente.
Seis pasos, un bucle: un diagnóstico fallido le devuelve al snapshot, no hacia delante con un paquete parcheado.
Paso 1: una máquina genuinamente limpia
Este es el paso que la gente se salta y luego paga.
La captura funciona comparando la máquina antes y después de la instalación. Todo lo que ya está presente es invisible para esa comparación, así que una máquina con las dependencias de la aplicación ya instaladas produce un paquete que funciona en su máquina y en ninguna otra parte.
Use una máquina virtual nueva, que coincida con la compilación de Windows objetivo, sin nada en ella más allá del sistema operativo. Tome un snapshot antes de empezar para poder volver a un estado conocido, porque va a hacer esto más de una vez.
Dos detalles marcan la diferencia entre una captura limpia y una ruidosa:
- Calme la máquina primero. Windows Update, las definiciones de seguridad y las actualizaciones de apps de la tienda escriben todas en disco mientras corre su captura, y cada una de esas escrituras pasa a formar parte del paquete. Deje que la máquina termine sus actualizaciones iniciales, páuselas y luego tome el snapshot.
- Haga coincidir la compilación, no solo la versión. Capturar en una compilación de Windows más nueva que la que ejecuta su parque hornea redistribuibles y versiones de framework presentes allí y ausentes en el destino. Capture en la compilación más antigua que soporte.
Un intento de captura en una máquina que carga una instalación fallida no vale nada, así que revierta antes de cada reintento.
Paso 2: capturar la instalación
Tome la línea base, ejecute el instalador exactamente como lo haría un usuario, y luego complete la captura.
Dos cosas que merece la pena hacer durante la instalación:
Inicie la aplicación una vez antes de terminar la captura. Muchas aplicaciones hacen una configuración de primer arranque: crear configuración, escribir valores predeterminados en el registry, desempaquetar recursos. Si captura antes de que eso ocurra, empaqueta una aplicación que nunca se ha inicializado y hará su primer arranque dentro del contenedor, donde la escritura puede no persistir.
Anote todo lo que el instalador le pregunte. Claves de licencia, direcciones de servidor, ubicaciones de instalación. Esas elecciones quedan ahora horneadas en el paquete, y si estaban mal, va a reconstruir.
Aquí también fija la identidad del paquete, y es incómodo cambiarla después:
<Identity Name="Contoso.LineOfBusinessApp"
Publisher="CN=Contoso Ltd, O=Contoso Ltd, C=GB"
Version="1.0.0.0" />
Publisher es el que importa: debe coincidir con el subject de su certificado de firma carácter por carácter, así que decídalo ahora en lugar de descubrir un desajuste en el paso cuatro. Version es un número de cuatro partes y al despliegue le importa que aumente, así que adopte una convención y anótela.
Si no hay ningún instalador, la captura no es su camino: reempaquetar sin el instalador original cubre ese caso en su lugar.
Paso 3: espere que se porte mal, y diagnostique como es debido
El paquete se instalará. Luego algo no irá bien.
No empiece a aplicar arreglos de forma especulativa. Reproduzca el problema como usuario estándar, averigüe qué está pidiendo realmente la aplicación, y haga coincidir el síntoma con una causa concreta. Cubrimos ese mapeo en qué ajuste de PSF necesito, y la versión corta es: compruebe el directorio de trabajo antes de recurrir a cualquier otra cosa, porque es la causa más común con diferencia.
Dos hábitos mantienen esto corto. Reproduzca como usuario estándar, porque buena parte de las roturas de MSIX que se reportan son una suposición de permisos que siempre estuvo en la aplicación y quedaba enmascarada porque todo el mundo trabajaba como administrador local. Luego mire dónde puso el contenedor la escritura: los datos por usuario aterrizan bajo %LOCALAPPDATA%\Packages\<PackageFamilyName>\LocalCache, y encontrar el archivo ahí demuestra que la escritura tuvo éxito y que la aplicación está mirando en el sitio antiguo.
Aplique un cambio cada vez y vuelva a probar. Un paquete que carga cuatro ajustes donde hacía falta uno es un paquete que nadie va a mantener.
Si el tercer ajuste no lo ha resuelto, replantee el objetivo. Convertir una aplicación heredada a MSIX cubre esa decisión, y no hay vergüenza en entregar una aplicación incómoda de otra manera.
Paso 4: fírmelo
Un MSIX sin firmar no se instalará en un dispositivo gestionado. Esto no es opcional y es donde se paran muchos primeros intentos.
Necesita un certificado de firma de código cuyo subject coincida exactamente con el publisher del manifiesto del paquete. No aproximadamente. Exactamente. Un desajuste aquí produce un fallo de instalación cuyo mensaje de error no menciona el certificado en absoluto, que es por lo que le cuesta a la gente una tarde. Compare los dos directamente antes de firmar:
Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert |
Select-Object Subject, Thumbprint, NotAfter
Lo que devuelva bajo Subject va en el Publisher del manifiesto, incluido el orden y los espacios de los nombres distinguidos relativos. Cópielo en lugar de teclearlo.
Firme desde el almacén de certificados por huella digital en lugar de manejar un archivo PFX, y use un servidor de marca de tiempo RFC 3161. Sin marca de tiempo el paquete deja de validar cuando el certificado caduca, aunque se firmara legítimamente mientras ese certificado estaba vigente.
signtool sign /sha1 <thumbprint> /fd SHA256 /tr <your RFC 3161 timestamp URL> /td SHA256 .\ContosoApp.msix
Una cosa más pilla a los certificados internos: el certificado tiene que ser de confianza en el dispositivo que instala el paquete. Una autoridad pública ya encadena a una raíz en la que Windows confía; su propia autoridad interna o un certificado de prueba autofirmado no lo hace, así que tiene que llegar antes al almacén de confianza del dispositivo. Distribúyalo a través de su gestión de certificados habitual, no a mano en una máquina de prueba, o su validación pasará en el único dispositivo donde podría.
Paso 5: valide antes de enviarlo
Valide el paquete y trate una salida distinta de cero como una parada. Es mucho más barato encontrar un manifiesto malformado ahora que después de que llegue a un anillo de prueba.
Confirme que la firma y la marca de tiempo también aterrizaron:
Get-AuthenticodeSignature .\ContosoApp.msix |
Format-List Status, SignerCertificate, TimeStamperCertificate
Status debería leer Valid y TimeStamperCertificate no debería estar vacío. Un campo de marca de tiempo vacío es un paquete que deja de instalarse en alguna fecha futura sin razón visible.
Luego instálelo de verdad en una máquina limpia, como usuario estándar, y compruebe:
- Arranca.
- Conserva los ajustes tras un reinicio.
- Se desinstala limpiamente y no deja nada detrás.
Add-AppxPackage .\ContosoApp.msix
Get-AppxPackage -Name Contoso.LineOfBusinessApp | Select-Object Name, Version, PackageFullName
Remove-AppxPackage -Package <PackageFullName>
Eso último es el sentido de MSIX. Si la desinstalación deja restos, algo se está escribiendo fuera del contenedor y no ha terminado.
Añada una cuarta comprobación si la gente mantiene la aplicación abierta todo el día: instálela, iníciela, y luego instale encima una versión incrementada. Las actualizaciones se preparan mientras la aplicación se ejecuta y se aplican cuando arranca la siguiente vez, así que un usuario que nunca la cierra nunca recibe la actualización. No es un error, pero sí una llamada a soporte si nadie lo esperaba.
Paso 6: desplegar a través de Intune
Empaquete el MSIX para Intune y asígnelo. En el centro de administración de Intune esto es Aplicaciones, Todas las aplicaciones, Agregar, y luego el tipo de aplicación de línea de negocio, que acepta el archivo .msix directamente. Asígnelo como requerido a un grupo piloto primero, y como disponible a todos una vez que el piloto haya aguantado.
Conviene saberlo: el MSIX desplegado de esta forma se actualiza por versión, así que su esquema de versionado ahora importa. Equivóquese una vez y los dispositivos rechazarán la actualización porque la versión no aumentó. Vigile el estado de instalación por dispositivo en lugar de confiar en la asignación, y tenga en cuenta que un dispositivo que ya lleva una copia firmada por un publisher distinto rechazará la gestionada, porque para Windows son aplicaciones diferentes.
Dónde se va el tiempo de verdad
No en la conversión. La conversión son minutos. El tiempo se va en la disciplina de máquina limpia, en el diagnóstico cuando la aplicación se porta mal, y en la configuración de firma. Hacer una aplicación le enseña el patrón. Hacer cuatrocientas es un problema distinto, y la razón por la que el empaquetado de aplicaciones sigue siendo un trabajo de especialista.
La diferencia no es el esfuerzo por aplicación, es la consistencia: si cada paquete se capturó en la misma compilación, se firmó de la misma manera, y sus decisiones de ajustes quedaron registradas en algún sitio que no sea la memoria de una persona. Eso es un problema de flujo de trabajo más que un problema de empaquetado, y es por lo que los estates acaban con paquetes que nadie se atreve a reconstruir.
Dónde encaja EtherApps Forge
EtherApps Forge está construido para el caso de las cuatrocientas: capturar, enrutar, preparar los ajustes, firmar y validar como un solo flujo en lugar de seis herramientas y un runbook. Las decisiones quedan registradas con el paquete en lugar de recordadas, que es lo que hace que la segunda pasada por un estate salga más barata que la primera.
Es una aplicación de escritorio de Windows y no un servicio alojado, así que la captura y la firma se quedan dentro de su entorno, y funciona con una prueba gratuita de 7 días. Si usted distribuye sus propias compilaciones en lugar de capturar el instalador de otro, el camino empieza desde una carpeta de compilación: empaquetado MSIX para desarrolladores e ISVs lo cubre, y compilar y firmar MSIX en CI/CD sin el Windows SDK muestra la forma del pipeline. Para la vista de todo el estate, empaquetado y despliegue MSIX va de la captura a la entrega.
Explore el empaquetado y despliegue MSIX para ver cómo la captura, la remediación, la firma y la entrega funcionan como un solo flujo en lugar de seis.