Les actions winget de Level s'exécutent en tant qu'utilisateur SYSTEM et imposent le scope machine sur toutes les opérations. La plupart des défaillances d'installation et de mise à jour remontent à l'une de ces deux contraintes. Les comprendre d'avance résout la majorité des problèmes signalés.

Comment Level exécute Winget

Deux choses sont toujours vraies pour chaque action winget de Level :

S'exécute en tant que SYSTEM : Level exécute winget sous le compte SYSTEM, non comme un utilisateur connecté ou une session d'administrateur standard. Tout comportement de paquet qui dépend du contexte utilisateur ne fonctionnera pas de la même manière.
Impose le scope machine : Level ajoute --scope machine à toutes les opérations winget. Seuls les paquets avec un scope machine défini dans leur manifeste peuvent être installés ou mis à jour via Level.

Ces deux contraintes expliquent presque chaque rapport « ça fonctionne dans PowerShell mais pas dans Level ».

Problèmes courants

Le paquet s'installe via PowerShell mais pas via Level

Si vous pouvez installer un paquet en tant qu'utilisateur actuellement connecté mais que l'action Level échoue, la différence est le contexte utilisateur. Level s'exécute en tant que SYSTEM, qui a un environnement et un registre différents de celui d'un utilisateur connecté. La plupart du temps, cela se manifeste par un problème de permission ou un chemin de profil utilisateur manquant.

Il n'y a pas de solution pour les paquets qui nécessitent fondamentalement une session utilisateur. Pour ceux-ci, envisagez une approche basée sur script avec PsExec ou une tâche programmée s'exécutant dans un contexte utilisateur spécifique.

Le paquet s'installe en tant qu'admin mais pas via Level

Level impose le scope machine. Un paquet peut s'installer correctement en tant qu'admin sans --scope machine mais échoue lorsque le scope machine est requis.

Testez-le directement pour confirmer :

winget install --scope machine -e --id PACKAGE_ID

Si cela échoue dans une session PowerShell administrateur, le paquet ne fournit pas d'installateur de scope machine. Level ne peut pas l'installer via l'action winget. Les seules options sont de trouver un ID de paquet alternatif qui supporte le scope machine, ou de l'installer via une action Exécuter le script avec un installateur différent.

L'action de mise à jour affiche moins de paquets que prévu

Level ajoute --scope machine aux analyses de mise à jour, de sorte que seules les installations avec scope machine apparaissent dans la liste de mise à jour.

Vous pouvez vérifier en exécutant vous-même la commande équivalente :

winget upgrade --scope machine --all

Si les résultats correspondent à ce que Level affiche, Level est précis. Les paquets installés sous un scope utilisateur n'apparaîtront pas.

L'installation du paquet expire dans Level mais fonctionne via PowerShell administrateur

C'est rare. Cela se produit lorsque l'installateur du paquet ne gère pas correctement le mode silencieux/discret et attend une interaction utilisateur qui ne peut jamais arriver, puisque Level s'exécute en tant que SYSTEM sans interface utilisateur. Il n'y a pas de solution pour cela — le problème est avec l'installateur lui-même. Vérifiez les problèmes ouverts du paquet dans le référentiel winget-pkgs.

Exclure un paquet des mises à jour automatiques

L'action Mettre à jour le paquet Winget a un champ intégré Paquet(s) exclu(s). Entrez un ou plusieurs ID de paquet là et ces paquets sont ignorés lors de l'exécution de la mise à jour — pas besoin d'épingler ou de contournements de ligne de commande.

Vérifier si un paquet supporte le scope machine

La vérification définitive est le manifeste du paquet dans le référentiel winget-pkgs. Recherchez InstallerScope: machine dans le manifeste. S'il est absent ou défini sur user, l'action winget de Level ne pourra pas l'installer.

Le raccourci pratique : exécutez la commande winget install --scope machine ci-dessus dans une session PowerShell administrateur. Si cela fonctionne là, cela fonctionnera dans Level.

FAQ

Level utilise-t-il le winget standard de Microsoft ou sa propre version ? Level installe et gère sa propre implémentation de winget. L'action Installer Winget (ou toute autre action winget, qui l'installe automatiquement) configure la version gérée de Level. Cela garantit un comportement cohérent sur vos appareils quel que soit le numéro de version de winget (le cas échéant) qui était déjà présent.
Je ne trouve pas un ID de paquet. Où dois-je chercher ? Recherchez dans le référentiel winget-pkgs ou exécutez winget search <name> dans une session PowerShell sur un appareil où le winget de Level est installé. L'ID que vous trouvez est ce que vous mettez dans l'action Level.
Puis-je exécuter des commandes winget directement depuis le terminal de Level ? Oui. Le terminal d'arrière-plan de Level s'exécute en tant que SYSTEM, de sorte que les contraintes de scope machine et de contexte SYSTEM s'appliquent également. Testez d'abord les commandes dans le terminal avant de les intégrer dans une automatisation.
Un paquet a été récemment ajouté à winget-pkgs mais Level ne le montre pas comme disponible. L'implémentation winget de Level peut légèrement traîner derrière le référentiel communautaire. Si un paquet très récent n'apparaît pas, vérifiez si le scope --scope machine est déjà défini dans le manifeste.

Dépannage de Winget