Las acciones de winget de Level se ejecutan como el SYSTEM usuario y aplica el ámbito de máquina en todas las operaciones. La mayoría de los errores de instalación y actualización se deben a una de estas dos restricciones. Comprenderlas desde el principio resuelve la mayoría de los problemas notificados.

Las acciones de instalación, actualización y desinstalación de paquetes de Level usan la API del Administrador de paquetes de Windows de Microsoft. No dependen de una sesión interactiva de PowerShell ni de la configuración de winget del usuario que ha iniciado sesión. La acción separada Instalar Winget instala la herramienta winget.exe herramienta de línea de comandos.

Dos cosas son siempre ciertas para cada acción de paquetes de winget de Level:

Estas dos restricciones explican casi todos los informes del tipo «funciona en PowerShell pero no en Level».

Si puede instalar un paquete como el usuario que ha iniciado sesión actualmente pero la acción de Level falla, la diferencia es el contexto de usuario. Level se ejecuta como SYSTEM, que tiene un entorno y un registro diferentes a los de un usuario que ha iniciado sesión. La mayoría de las veces esto se manifiesta como un problema de permisos o una ruta de perfil de usuario faltante.

No hay solución alternativa para los paquetes que fundamentalmente requieren una sesión de usuario. Para esos, considere un enfoque basado en scripts con PsExec o una tarea programada que se ejecuta bajo un contexto de usuario específico.

Level aplica el ámbito de máquina. Un paquete puede instalarse correctamente como administrador sin --scope machine pero fallan cuando se requiere ámbito de máquina.

Pruébelo directamente para confirmarlo:

Si esto falla en una sesión de PowerShell con permisos de administrador, el paquete no proporciona un instalador de ámbito de máquina. Level no puede instalarlo mediante la acción de winget. Las únicas opciones son encontrar un ID de paquete alternativo que admita el ámbito de máquina, o instalarlo mediante una acción Ejecutar Script con un instalador diferente.

Level usa el ámbito de máquina para los análisis de actualización, por lo que solo aparecen en la lista de actualizaciones las instalaciones con ámbito de máquina.

Puede verificarlo ejecutando usted mismo el comando equivalente:

Si los resultados coinciden con lo que muestra Level, Level es preciso. Los paquetes instalados con ámbito de usuario no aparecerán.

Si la salida de la acción indica operation timed out, el Administrador de paquetes de Windows no finalizó la operación del paquete en aproximadamente 30 minutos. Esto ocurre con frecuencia cuando un instalador se detiene o espera una interacción del usuario que no puede proporcionarse mientras Level se ejecuta en modo silencioso como SYSTEM.

Revise la salida de la acción en busca de un nombre de proceso bloqueado o un mensaje que indique que la aplicación está en uso. Cierre la aplicación e inténtelo de nuevo cuando sea posible. Si el mismo paquete agota repetidamente el tiempo de espera, agregue su ID de paquete a Paquete(s) excluido(s) en una acción Actualizar todo e impleméntelo con el instalador silencioso compatible del proveedor o con una acción Ejecutar Script.

La acción Actualizar paquete Winget acción tiene un Paquete(s) excluido(s) campo. Introduzca uno o más IDs de paquete allí y esos paquetes se omitirán durante la ejecución de la actualización, sin necesidad de anclar ni usar soluciones alternativas de línea de comandos.

La verificación definitiva es el manifiesto del paquete en el repositorio winget-pkgs. Busque InstallerScope: machine en el manifiesto. Si está ausente o configurado como user, la acción de winget de Level no podrá instalarlo.

El atajo práctico: ejecute el winget install --scope machine comando anterior en una sesión de PowerShell con permisos de administrador. Si tiene éxito allí, funcionará en Level.