I keep hitting this problem when I try to debug my Windows 8 apps and there is a copy already installed on another user account:
DEP0700 : Registration of the app failed. Another user has already installed a packaged version of this app. An unpackaged version cannot replace this. The conflicting package is {{{PackageName}}} and it was published by CN={{{Certificate Stuff}}}. (0x80073cf9)
Sometimes I can just log in or ask someone else to log in to the machine and uninstall the app. Alternatively I can change the application name/id, but one is not always possible and the other is risky (I don't want to check in the changed application id to source control).
There must be some way to uninstall it. Maybe a PowerShell script?
My process above still works, but it simply gets around a race condition issue, where Windows Update (yes, oddly enough) is in charge of wiping out "staged packages."
According to Microsoft, the "other fix" - and I still consider this issue to be a bug - is:
Cause of the problem:
Windows Update (WU) downloads newer versions of packages you have and “stages” them as Local System, so that when you go to the store to update the apps, the update process is as quick as possible. WU will eventually clean up the staged packages that were never installed.
What are some consequences of having "Staged" packages?
Staged packages prevent you from installing that particular package in development mode
Staged packages eat up some disk space, but due to hardlinking, the effect of this is mitigated. If a file is identical between multiple versions of a package, appx deployment hardlinks the files instead of maintaining two separate copies of the same file.
How do I find the "Staged" packages?
In an administrator powershell prompt, the command:
get-appxpackage -all
will display all packages on the machine. For a staged package, the PackageUserInformation will show {S-1-5-18 [Unknown user]: Staged} 2. Using powershell filtering, to get the list of all staged packagefullnames, you could do:
get-appxpackage -all |% {if ($_.packageuserinformation.installstate -eq "Staged"){$_.packagefullname}}
How do I get rid of the "Staged" packages?
Download
psexec
from sysinternals tools, written by Mark RussinovichTo get rid of all of them, run in a regular admin/elevated command prompt (not powershell):
psexec -s powershell -c "get-appxpackage | remove-appxpackage"
If that doesn't work, you can also try the following, which worked for me. Note that this is for my dev machine, not a regular user's machine, so I don't know how it would affect non-devs :-P
Take ownership of the folders c:\Program Files\WindowsApps and C:\ProgramData\Microsoft\Windows\AppRepository - giving Administrator full access. Make sure TrustedInstaller also has Modify rights as well. You're also taking ownership. If you're unawares, this is done via the Properties on that folder.
Go to Services and stop the Windows Installer service.
Open C:\ProgramData\Microsoft\Windows\AppRepository\ and delete the PackageRepository.edb file.
Start the Windows Installer service again.
Launch Visual Studio as Administrator.
Attempt to launch your app. It should work.
After you run the app once you should be able to run VS in user mode again.
There was an improvement in Windows 10 1709 to the remove-appxpackage cmdlet, adding -allusers as an option.
So, to uninstall an App for all users, this command works:
Get-AppxPackage -AllUsers [PackageFamilyName] | Remove-AppxPackage -AllUsers
Where [PackageFamilyName] is generally the GUID of your package.
Caveat / Caution: The command seems to make re-installation (re-provisioning the package using DISM) later very difficult, as it seems to treat is as if each user individually uninstalled the app. Too much to get into here...
Workaround:
If nothing else works for you (for me it didnt either), you can just change your Package Name in your app manifest (just replace last few characters with another characters). When you do this, you will no longer have conflicting packages.
Changing package name may not be appropriate for some scenarios, but you can always back it up and change it back when you finished debugging on your problematic device....
If you want to delete the app for the current user then try:
Get-AppxPackage | where name -eq "APP.NAME" | Remove-AppxPackage
It helped me. So there is Get-AppxPackage
without -all
On windows 10 :
First, you need an SQL database editor like SqliteBrowser3
C:\ProgramData\Microsoft\Windows\AppRepository\StateRepository-Machine.srd
user
column from "packageuser" table.tasklist /svc /fi "services eq StateRepository"
StateRepository-Machine.srd
after backup.Note : you need to leave your own user entry assigned to the package
There is a set of PowerShell cmdlets for managing Windows Store apps. You can list the installed apps on the machine for all the users if you run the following command as an administrator:
Get-AppxPackage -AllUsers
I haven't found a way to uninstall an app for a different user, though. Remove-AppxPackage
works only for the current user. This makes everything even more interesting if you delete a user having apps installed. At least in prerelease versions of Windows 8 this made it impossible to delete an app he had installed. I managed to successfully avoid such a situation since final release therefore I can't confirm the problem is still present, i.e. apps aren't uninstalled when a user account is deleted.
I had to do the following:
get-appxpackage -all > log.txt
notepad log.txt (search for the offending PackageFullName)
remove-appxpackage -allusers -package "PackageFullName"
The key for me was to add the -allusers flag, since without it I received an "...because the current user does not have that package installed. Use Get-AppxPackage to see the list of packages installed." error.
This is similar to some other answers, especially @Pavel Nazarov's, but works for different users. And it's different from the accepted answer because you don't need to install any programs.
In Windows Powershell in admin mode, run:
get-appxpackage -all | where name -eq "{{ App Name }}" | remove-appxpackage
Though this didn't work for me, it may just work for someone else...
Start powershell as Administrator and run:
Get-AppxPackage -all | Out-GridView -Passthru | Remove-AppXPackage
Then SELECT the right package and OK, hopefully it will remove.
What worked for me
1. Close VS
2. Open Services
3. Stop Appx Deployment Service
4. Open C:\ProgramData\Microsoft\Windows\AppRepository\ and delete the PackageRepository.edb file.
5. Start Appx Deployment Service
6. Start VS & Debug - worked like charm
If all else fails and you are desperate, like was my case (because the user was deleted) This one is a little dangerous but it worked for me.
DO AT YOUR OWN RISK! I knew that my user was the last user created on the machine.
This answer is a combination of Auri Rahimzadeh's answer above on TAKEOWN and intika's answer where you modify the StateRepository-Machine.srd using 'DB Browser For SQLite' (downloaded here: DB Browser for SQLite 3), the only difference is I only edited one thing: In PackageUser I changed the value User 3 (Which was the ID of the previous deleted User) to 4 (Which is me, the last created User)
BE SURE TO CHECK THE User Table AND SEE WHAT VALUES WORK IN YOUR CASE!
I just used get-appxpackage -all | where name -eq "PackageName" | remove-appxpackage -AllUsers
on Win 10 v1903 after trying many other variations and it worked. I tested for the package's presence afterwards and it was gone.
User contributions licensed under CC BY-SA 3.0