Introduction

Les actions winget de Level s'exécutent en tant qu'utilisateur SYSTEM et imposent la portée machine à toutes les opérations. La plupart des échecs d'installation et de mise à niveau sont liés à l'une de ces deux contraintes. Les comprendre dès le départ permet de résoudre 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 et non en tant qu'utilisateur connecté ou session d'administration standard. Tout comportement de paquet dépendant du contexte utilisateur ne fonctionnera pas de la même manière.
Impose la portée machine: Level ajoute --scope machine à toutes les opérations winget. Seuls les paquets dont la portée machine est définie dans leur manifeste peuvent être installés ou mis à niveau via Level.

Ces deux contraintes expliquent presque tous les rapports du type « ç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 réside dans le contexte utilisateur. Level s'exécute en tant que SYSTEM, qui dispose d'un environnement et d'un registre différents de ceux d'un utilisateur connecté. La plupart du temps, cela se manifeste par un problème de permissions ou un chemin de profil utilisateur manquant.

Il n'existe aucune solution de contournement pour les paquets qui nécessitent fondamentalement une session utilisateur. Pour ceux-là, envisagez une approche basée sur un script avec PsExec ou une tâche planifiée s'exécutant dans un contexte utilisateur spécifique.

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

Level impose la portée machine. Un paquet peut s'installer correctement en tant qu'administrateur sans --scope machine mais échouent lorsque la portée machine est requise.

Testez-le directement pour confirmer :

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

Si cela échoue dans une session PowerShell en mode administrateur, le paquet ne fournit pas de programme d'installation à portée machine. Level ne peut pas l'installer via l'action winget. Les seules options sont de trouver un ID de paquet alternatif prenant en charge la portée machine, ou de l'installer via une action Exécuter un script avec un programme d'installation différent.

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

Level ajoute --scope machine aux analyses de mise à niveau, donc seules les installations à portée machine apparaissent dans la liste des mises à niveau.

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 dans une portée utilisateur n'apparaîtront pas.

L'installation du paquet expire dans Level mais fonctionne via PowerShell en mode admin

C'est rare. Cela se produit lorsque le programme d'installation du paquet ne gère pas correctement le mode silencieux/discret et attend une interaction utilisateur qui ne peut jamais arriver, car Level s'exécute en tant que SYSTEM sans interface utilisateur. Il n'existe aucune solution de contournement pour cela — le problème vient du programme d'installation lui-même. Consultez les problèmes ouverts du paquet dans le dépôt winget-pkgs.

Exclure un paquet des mises à jour automatiques

L'action Upgrade Winget Package dispose d'un champ intégré Paquet(s) exclus . Saisissez un ou plusieurs ID de paquets et ces paquets seront ignorés lors de l'exécution de la mise à niveau — aucun épinglage ni contournement en ligne de commande n'est nécessaire.

Vérifier si un paquet prend en charge la portée machine

La vérification définitive est le manifeste du paquet dans le dépôt 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 dans une session PowerShell en mode administrateur. Si cela réussit, 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 Install 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 tous vos appareils, quelle que soit la version de winget (le cas échéant) déjà présente.
Je ne trouve pas un ID de paquet. Où dois-je chercher ? Recherchez dans le dépôt 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 celui à saisir dans l'action Level.
Puis-je exécuter des commandes winget directement depuis le terminal de Level ? Oui. Le terminal en arrière-plan de Level s'exécute en tant que SYSTEM, donc les contraintes de portée machine et de contexte SYSTEM s'y 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 l'affiche pas comme disponible. L'implémentation winget de Level peut légèrement être en retard par rapport au dépôt communautaire. Si un paquet très récent n'apparaît pas, vérifiez si la portée --scope machine n'est pas encore défini dans le manifeste.

Dépannage de Winget