De App-V a MSIX: las cuatro cosas que se rompen siempre

Convertir paquetes App-V a MSIX es en su mayor parte mecánico hasta que deja de serlo. Cuatro cosas explican la abrumadora mayoría de los reportes del tipo "convirtió bien y ahora se comporta raro", y son las mismas cuatro cada vez.

Merece la pena conocerlas antes de empezar, porque cada una es barata de tratar de forma deliberada y cara de descubrir en un anillo de pruebas.

La razón de fondo es la misma en los cuatro casos: App-V virtualizaba cosas que App-V controlaba, y MSIX las encapsula de otra manera. Todo aquello que la aplicación confiaba a App-V necesita una respuesta nueva. Nada de esto es un fallo de MSIX. Los dos formatos simplemente trazan la línea entre paquete y entorno en lugares distintos.

Abra el paquete antes de convertirlo

Un paquete App-V 5 no es opaco. El archivo .appv es un contenedor OPC, en la práctica un zip con un manifiesto dentro, así que todo lo que necesita es legible antes de que una herramienta de conversión lo toque.

Tres archivos llevan el comportamiento:

• AppxManifest.xml, dentro del .appv, contiene los valores por defecto producidos cuando se secuenció la aplicación.
• <PackageName>_DeploymentConfig.xml lleva los ajustes de máquina y los scripts en contexto de máquina.
• <PackageName>_UserConfig.xml lleva los ajustes por usuario y los scripts en contexto de usuario.

La precedencia va de UserConfig sobre DeploymentConfig sobre el manifiesto, así que un ajuste puede aparecer en los tres con valores distintos y solo uno está vivo. Lea solo el manifiesto y se perderá las personalizaciones añadidas después para que la aplicación funcionara, que son las que soportan carga.

Extraerlos lleva segundos:

Copy-Item .\LineOfBusinessApp.appv .\LineOfBusinessApp.zip
Expand-Archive .\LineOfBusinessApp.zip -DestinationPath .\LineOfBusinessApp
Select-Xml -Path .\LineOfBusinessApp\AppxManifest.xml -XPath '//*[local-name()="EnvironmentVariables" or local-name()="Shortcut" or local-name()="FileTypeAssociation"]' | ForEach-Object { $_.Node.OuterXml }

Lea primero las tres fuentes de configuración, luego enrute cada hallazgo a donde ahora corresponde.

1. Variables de entorno

App-V permitía definir variables de entorno en el paquete, y la aplicación las veía dentro de su entorno virtual. Residen en un subsistema <EnvironmentVariables>, y cualquiera de los dos archivos de configuración puede añadirlas o borrarlas:

<EnvironmentVariables Enabled="true">
  <Include>
    <Variable Name="LOBAPP_DATA" Value="%UserProfile%\LineOfBusinessApp" />
  </Include>
</EnvironmentVariables>

MSIX maneja esto de forma diferente, y las variables que declaró en App-V no llegan. Una aplicación que lee una variable para encontrar una ruta de datos, un nombre de servidor o una ubicación de licencia arranca y se comporta como si nunca hubiera sido configurada. Funciona, simplemente no sabe nada.

Qué hacer: enumere las variables que declaraba el paquete antes de convertir. La gente se salta esto, porque las variables no son visibles en la propia configuración de la aplicación. Después decida para cada una: una variable de nivel de máquina o de usuario fijada por sus herramientas de despliegue, un valor en un archivo de configuración que la aplicación lee, o algo que un script de arranque fija primero.

La firma del fallo es una aplicación que arranca limpiamente y luego se queja de un servidor o una ruta que faltan. Vigile la variante más silenciosa, en la que recurre a un valor por defecto interno en lugar de dar error y aflora semanas después.

2. Accesos directos

Los paquetes App-V llevaban sus definiciones de accesos directos completas. El elemento <Shortcut> nombra el .lnk que se debe crear, su <Target>, <Icon>, <Arguments>, <WorkingDirectory> y <Description>, de modo que un paquete secuenciado reproducía lo que el instalador hubiera dejado en el menú Inicio.

MSIX genera su entrada a partir del manifiesto del paquete en su lugar, y el resultado no siempre es lo que producía App-V. El acceso directo aterriza en otro sitio, el icono es incorrecto o falta, o los argumentos de línea de comandos han desaparecido.

Ese último es el peligroso. Si el acceso directo de App-V pasaba un argumento que ponía la aplicación en un modo concreto y la entrada MSIX no lo hace, los usuarios obtienen una aplicación que se abre en el estado equivocado en lugar de una que falla de forma visible. Publicar la misma aplicación dos veces, como "Finanzas" y como "Solo lectura", con la diferencia contenida enteramente en un modificador, es más común de lo que querría.

Qué hacer: capture la definición completa del acceso directo, incluidos los argumentos y el directorio de trabajo, y reprodúzcala de forma deliberada. Cuando un argumento distingue realmente dos formas de ejecutar la aplicación, eso suele convertirse en dos entradas de aplicación en el manifiesto.

Compruebe el directorio de trabajo en concreto. Si nada lo fija, Windows usa el directorio System32 para una aplicación empaquetada, que es por lo que "no encuentra sus propios archivos" es un primer síntoma tan común. El Package Support Framework lo fija explícitamente con un valor workingDirectory en config.json, el ajuste que más se aplica tras cualquier conversión. Qué ajuste de PSF necesito mapea el resto.

3. Scripts

Esta es la mayor diferencia individual y la que descarrila las migraciones.

App-V soportaba scripts en ocho puntos del ciclo de vida, lo que explica cuánta lógica acumulan los estates sin registrarla:

Los estates de App-V de larga duración a menudo tienen lógica real en esos scripts: mapear una unidad, obtener configuración, limpiar una ubicación temporal, registrar algo. Varios scripts pueden colgar de un disparador mediante ScriptRunner.exe, así que una sola entrada AddPackage puede ejecutar cuatro cosas en secuencia.

MSIX no ofrece los mismos ganchos de script de ciclo de vida. El equivalente más cercano es el Package Support Framework, que ejecuta un script de PowerShell antes de un ejecutable empaquetado y otro después de que salga, fijados por ejecutable como startScript y endScript en config.json.

Eso cubre StartProcess y ExitProcess. No cubre los otros seis. Todo lo que se ejecutaba al añadir, publicar, despublicar o quitar se traslada a sus herramientas de despliegue, lo único que ahora sabe cuándo llega o se va un paquete.

Qué hacer: encuentre los scripts antes de convertir, y léalos. Algunos se convierten en comportamiento de instalación o desinstalación en Intune o Configuration Manager. Algunos se convierten en un script de arranque dentro del paquete. Algunos se convierten en configuración de la aplicación. Algunos duplican lo que la plataforma ya hace de forma nativa, y se pueden borrar con alivio.

Dos notas prácticas. La ejecución de scripts necesita la política de ejecución de PowerShell fijada en RemoteSigned tanto para el host de 64 bits como para el de 32 bits. Y StartingScriptWrapper.ps1 tiene que estar en el paquete junto al ejecutable, o no se ejecuta nada y nada explica por qué.

La firma del fallo aquí es la peor de las cuatro, porque la aplicación funciona perfectamente para la persona que la prueba, cuya unidad ya estaba mapeada.

4. Asociaciones de tipo de archivo

App-V registraba las asociaciones dentro de su entorno virtual con detalle: la extensión, su ProgId, los nombres descriptivos y los comandos de shell con sus propias líneas de comandos, de modo que un verbo "Editar" del clic derecho podía lanzar el ejecutable con un modificador distinto al de "Abrir".

MSIX las declara en el manifiesto como una extensión, y la declaración tiene que ser correcta:

<uap:Extension Category="windows.fileTypeAssociation">
  <uap:FileTypeAssociation Name="lobdoc">
    <uap:SupportedFileTypes>
      <uap:FileType>.lob</uap:FileType>
    </uap:SupportedFileTypes>
  </uap:FileTypeAssociation>
</uap:Extension>

Cuatro cosas salen mal, en un orden aproximado de frecuencia.

La asociación no se declara en absoluto, así que hacer doble clic en un archivo no hace nada útil.

Se declara pero Windows no la respeta, porque otra aplicación ya posee esa extensión y la elección del usuario gana. El resultado funciona en la máquina de empaquetado y no en el dispositivo de un usuario real.

El Name es incorrecto. Tiene que ir en minúsculas, y debería mantenerse estable entre actualizaciones, porque es el identificador bajo el que Windows agrupa los tipos de archivo.

La extensión está reservada. Windows guarda extensiones y esquemas URI para las aplicaciones integradas, y un registro para una de ellas se ignora en lugar de rechazarse, así que parece que la declaración no surtió efecto.

Los verbos personalizados son la parte que se olvida. Los comandos de shell más allá de un simple abrir no sobreviven al viaje.

Qué hacer: liste las extensiones que registraba el paquete, con sus valores ProgId y cualquier comando de shell, declárelas en el manifiesto y pruebe en un dispositivo que tenga las aplicaciones que tiene un usuario real, no en una máquina virtual limpia sin reclamaciones que compitan.

Ya que está ahí, anote los protocolos URL, los AppPaths, los clientes de software y los ajustes COM que llevan esos mismos archivos. Un manejador lobapp:// que dejó de existir en silencio es un ticket confuso.

El orden que ahorra tiempo

Haga todo el descubrimiento antes de convertir nada:

1. Extraiga las variables de entorno que declara el paquete, de las tres fuentes.
2. Extraiga las definiciones de accesos directos, incluidos los argumentos y el directorio de trabajo.
3. Extraiga y lea los scripts, anotando de qué disparador cuelga cada uno.
4. Liste las asociaciones de tipo de archivo, sus valores ProgId y sus comandos de shell.
5. Anote los subsistemas restantes: protocolos URL, AppPaths, clientes de software, COM.

Registre la decisión junto a cada hallazgo, no solo el hallazgo. "Fija LOBAPP_DATA" es una nota. "Fija LOBAPP_DATA, pasa a ser una variable de usuario en el despliegue de Intune" es un plan.

Eso es una hora por aplicación como mucho, y convierte la conversión de descubrimiento en implementación. Sáltelo y encontrará cada uno de estos en un anillo de pruebas, con un usuario reportando el síntoma en lugar de la causa.

Un ejemplo. Una aplicación financiera convierte limpiamente, y luego afloran dos cosas en el piloto: no encuentra sus plantillas, porque el paquete fijaba una variable que apuntaba a un recurso compartido, y la mitad del grupo la abre en el modo equivocado, porque el acceso directo de App-V pasaba un modificador de solo lectura. Ambas estaban en _DeploymentConfig.xml antes de que nadie convirtiera nada.

Después convierta, y pruebe como usuario estándar en un dispositivo que se parezca a uno real.

Dónde encaja esto

La ruta de migración más amplia, incluido qué paquetes deberían convertirse en MSIX siquiera, está en migración de App-V a MSIX. Merece leerse junto a ella: el servidor de App-V termina, App-V no, porque el calendario es menos urgente de lo que sugirió la mayor parte de la cobertura y precipitar estas conversiones es como los cuatro problemas anteriores llegan a producción.

Conversión de legacy a MSIX cubre los mismos comportamientos de contenedor para aplicaciones que nunca pasaron por App-V.

Dónde encaja EtherApps Forge

EtherApps Forge captura aplicaciones desde entornos antiguos y escalona la remediación como parte del empaquetado en lugar de como un proyecto aparte posterior, de modo que la corrección del directorio de trabajo, la redirección de archivos y el script de arranque se deciden mientras se construye el paquete, no después de que un piloto haya fallado.

Es una aplicación de escritorio de Windows con una prueba gratuita de 7 días, no un servicio alojado, así que las capturas y las salidas permanecen dentro de su entorno. La ruta de apps heredadas cubre el descubrimiento y la remediación, empaquetado y despliegue MSIX cubre la firma, la validación y la entrega, y modernización y migración de aplicaciones cubre qué aplicaciones toman este camino siquiera.

Explore la modernización de aplicaciones heredadas

Responda a las cuatro preguntas antes de convertir, y la conversión deja de producir sorpresas.