Comment désinstaller une application qu'un autre utilisateur a installée ?

Question

Je rencontre toujours ce problème lorsque j'essaie de déboguer mes applications Windows 8 et qu'une copie est déjà installée sur un autre compte utilisateur :

DEP0700 : L'enregistrement de l'application a échoué. Un autre utilisateur a déjà installé une version packagée de cette application. Une version non emballée ne peut pas la remplacer. Le paquet en conflit est {{{NomduPackage}} et il a été publié par CN={{{Certificate Stuff}}. (0x80073cf9)

Parfois, je peux simplement me connecter ou demander à quelqu'un d'autre de se connecter à la machine et désinstaller l'application. Je peux aussi changer le nom/identifiant de l'application, mais l'un n'est pas toujours possible et l'autre est risqué (je ne veux pas vérifier l'identifiant modifié de l'application dans le contrôle de la source).

Il doit y avoir un moyen de le désinstaller. Peut-être un script PowerShell ?

Answer 1

Mon processus ci-dessus fonctionne toujours, mais il contourne simplement un problème de condition de course, où Windows Update (oui, bizarrement) est chargé d'effacer les "paquets mis à jour".

Selon Microsoft La solution de rechange - et je considère toujours ce problème comme un bogue - est la suivante :

Cause du problème :

Windows Update (WU) télécharge des versions plus récentes des paquets que vous possédez et les "met en scène" en tant que Système Local, de sorte que lorsque vous vous rendez au magasin pour mettre à jour les applications, le processus de mise à jour est aussi rapide que possible. WU va nettoiera éventuellement les paquets mis à disposition qui n'ont jamais été installés.

Quelles sont les conséquences de l'existence de paquets "Staged" ?

1. Les paquets mis à disposition vous empêchent d'installer ce paquet particulier en mode développement.

2. Les paquets échelonnés consomment un peu d'espace disque, mais grâce au hardlinking, l'effet de ce phénomène est atténué. Si un fichier est identique entre plusieurs versions d'un paquet, le déploiement d'appx lie les fichiers en dur au lieu de de maintenir deux copies séparées du même fichier.

Comment trouver les paquets "Staged" ?

1. Dans une invite powershell administrateur, la commande :

   get-appxpackage -all

affichera tous les paquets présents sur la machine. Pour un paquet mis à disposition, l'élément PackageUserInformation indiquera {S-1-5-18 [Utilisateur inconnu] : Staged} 2. En utilisant le filtrage powershell, pour obtenir la liste de tous les noms de paquets mis à disposition, vous pouvez faire ce qui suit :

get-appxpackage -all |% {if ($_.packageuserinformation.installstate -eq "Staged"){$_.packagefullname}}

Comment se débarrasser des paquets "Staged" ?

1. Télécharger psexec tiré de sysinternals tools, écrit par Mark Russinovich

2. Pour vous débarrasser de tous ces éléments, exécutez une invite de commande ordinaire (pas powershell) :

psexec -s powershell -c "get-appxpackage | remove-appxpackage"

Answer 2

Si cela ne fonctionne pas, vous pouvez également essayer ce qui suit, qui a fonctionné pour moi. Notez que c'est pour ma machine de développement, pas pour celle d'un utilisateur normal, donc je ne sais pas comment cela affecterait les non-développeurs :-P

1. S'approprier les dossiers c : \Program Fichiers \WindowsApps y C:\ProgramData\Microsoft\Windows\AppRepository - donnant à l'administrateur un accès complet. Assurez-vous que TrustedInstaller a également des droits de modification. Vous prenez également la propriété. Si vous n'êtes pas au courant, cela se fait via les propriétés de ce dossier.

2. Allez dans Services et arrêtez le service Windows Installer.

3. Abrir C:\ProgramData\Microsoft\Windows\AppRepository\ et supprimez le fichier PackageRepository.edb.

4. Redémarrez le service Windows Installer.

5. Lancez Visual Studio en tant qu'administrateur.

6. Essayez de lancer votre application. Cela devrait fonctionner.

Après avoir lancé l'application une fois, vous devriez être en mesure de lancer VS en mode utilisateur à nouveau.

Answer 3

Solution de rechange :

Si rien d'autre ne fonctionne pour vous (pour moi, ce n'était pas le cas non plus), vous pouvez simplement changer le nom de votre paquet dans votre manifeste d'application (il suffit de remplacer les derniers caractères par d'autres). En procédant ainsi, vous n'aurez plus de paquets en conflit.

Changer le nom du paquet peut ne pas être approprié pour certains scénarios, mais vous pouvez toujours le sauvegarder et le changer à nouveau lorsque vous avez terminé le débogage sur votre appareil problématique.....

Answer 4

Si vous voulez supprimer l'application pour l'utilisateur actuel, essayez :

Get-AppxPackage | where name -eq "APP.NAME" | Remove-AppxPackage

Cela m'a aidé. Donc il y a Get-AppxPackage sans -all

Answer 5

Il existe un ensemble de cmdlets PowerShell pour gérer les applications du Windows Store. Vous pouvez répertorier les applications installées sur la machine pour tous les utilisateurs si vous exécutez la commande suivante en tant qu'administrateur :

Get-AppxPackage -AllUsers

Je n'ai pas trouvé de moyen de désinstaller une application pour un autre utilisateur, cependant. Remove-AppxPackage ne fonctionne que pour l'utilisateur actuel. Cela rend les choses encore plus intéressantes si vous supprimez un utilisateur ayant des applications installées. Au moins dans les versions préliminaires de Windows 8, il était impossible de supprimer une application qu'il avait installée. J'ai réussi à éviter une telle situation depuis la version finale et je ne peux donc pas confirmer que le problème est toujours présent, c'est-à-dire que les applications ne sont pas désinstallées lorsqu'un compte utilisateur est supprimé.