Pack your Windows App package yourself

A while ago, one of my Windows Store apps was in a weird stall – I’ve updated the app to support Windows 8.1 only, but published version was still targeting 8.0. After uploading new version of the app, I had to remove the 8.0 version due to some validation errors – the mistake!

I was left in a situation where I couldn’t publish my new 8,1 app because the process required having the 8.0 along the new one. Uploading 8.0 version didn’t work either because the process required that any new upload has to have its version number incremented. An option to just end the Windows 8.0 support at this point would be a helpful solution to the problem, but that option is not available until both versions of the app are validated and published.

I had to manually increment the old app’s version (targeting 8.0) and put it up there for validation to be able to continue publishing the new app (targeting 8.1).

Luckily, the application’s version is easily modified in AppxManifest.xml and Appx files are just archive files, right? Yes, but any modification made to package content will invalidate package signature so it’s necessary to recreate it.

Creating the package

Starting from existing package, I have first unpacked it to a new folder and incremented the version in the app manifest. I could’ve also changed other content files if I needed to.

To recreate package, I’ve used the App Packager tool. It’s located in Windows SDK folder (8.0 or 8.1) and it’s pretty easy to use: just point it to the unpacked folder and specify a new package path:

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\makeappx.exe" pack /d <PathToMyUnpackedAppFolder> /p <PathToNewAppPackage>\<PackageName>.appx

If the tool complains about missing resource files, add the /l option – that will disable missing file validation for cases where multiple version of the same resource is included in the package (e.g. multiple bitmap scale variations).

Signing the package

When package is created, it has to be signed. The signing is done using a different tool called SignTool. Again, the process is pretty straightforward, but you’ll need to have a certificate to sign the package. It’s best to use the certificate that was created by Visual Studio when the solution was associated with the Store application. That certificate file should be named something like <AppName>_StoreKey.pfx.

"C:\Program Files (x86)\Windows Kits\8.0\bin\x86\SignTool" sign /fd SHA256 /a /f <PathToCertificate>\<AppName>_StoreKey.pfx <PathToNewAppPackage>\<PackageName>.appx

The default hashing algorithm used to hash files when creating packages is SHA256 and since SIgnTool uses a different default (SHA1), it’s necessary to set the /fd parameter to appropriate algorithm. If you haven’t created the app package yourself and you’re not sure what algorithm was used while creating, check the AppBlockMap.xml that should be in the package. The file includes all file hashes and first element’s HashMethod attribute must specify the algorithm used.

So this is it! If you’re ever stuck with the Store application package that can’t be (re)created using Visual Studio and you only need to make a few modifications to be able to deploy it to the Store, you can do It manually.
Of course the same applies if you’re automating your app building process to create deployment-ready packages as well.