Deployment of a development version of your Windows Store app package through Visual Studio 2012 can sometimes lead to an error that looks like this:

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 <<YourApp package name>> and it was published by CN=<<publisher ID>>. (0x80073cf9)

The following information should be helpful to understand why this error happens and how to resolve it:

What are "Staged" packages?

Windows Update 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. Windows Update will eventually clean up the staged packages that were never installed.

 

What are some of the consequences of having "Staged" packages?

1. Staged packages prevent you from installing a particular package in development mode and leads to an error like above

2. 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 "Staged" packages?

In an elevated Powershell prompt (Run as administrator), 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}

 To get a list of all staged packages, you can use Powershell filters to filter by the “packagefullnames” like this:

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

 

How do I get rid of "Staged" packages?

 

1. Download psexec from SysInternals tools, written by Mark Russinovich

2. To get rid of all the Staged packages, run the below command from an elevated command prompt (cmd.exe):

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

 Note: since you are running powershell from the System context, the only packages listed by get-appxpackage (and therefore deleted) are the staged packages!

Once the staged packages are cleaned up, you should no longer experience issues deploying app packages through Visual Studio 2012.

 

A general guidance and common error codes encountered during app package deployment are documented here: http://msdn.microsoft.com/en-us/library/windows/desktop/hh973484(v=vs.85).aspx.

 

Comments are welcome, both below and on twitter: #WSDevSol