Windows Phone 8.1 store package version change surprise – one act

UPDATE

This store bug has been fixed, feel free to ignore this post. More info here

—-

Yesterday, home office

Me
“Ok, new analytics checked in with a few error fixes, time to submit an app update for the Windows Phone app. I’ll just increment from 1.0.0.15 to 1.0.0.16 and Build.”

Visual Studio 

Me
“That’s weird, I’ve never seen that before. It looks like its using the appx date driven version number and my user friendly version number.”

Try again, same result. Restart Visual Studio, same result. Restart machine, same result.

Inspect Package.StoreAssociation.xml files.

“Hmm, the landing urls in the Windows 8.1 and Windows Phone 8.1 has been updated to match, but I was able to build and update the Windows app like normal. That’s confusing.”

Research, find a thread on the MS forums declaring it as normal. Post a rebuttal.

Contact MS Support via chat. Talk to a nice guy that confirms this is the new way it’s going to be, for now, until Windows 10, maybe.

Adapt and move along.

Conclusion
If you run into this error apparently that’s the new way its going to be and you can’t get around it. I updated the package version using the date format “2015.703.0.0” and I am now manually storing a user friendly version for display within the app “1.1.0”. The app uploaded and the user shouldn’t notice a difference.

Next time it would be great to get some kind of notice and understand why there is a difference between Windows and Windows Phone versioning.  My guess is this is just a growing pain and a side effect of the Store union and the oncoming Windows 10 store.

To see the app that has now hit version 2015, check out Wish on Windows Phone and plain old version 1.0 on Windows.

8 thoughts on “Windows Phone 8.1 store package version change surprise – one act

  1. Thanks for this post! I thought I was going crazy when I couldn’t make an update the same way I had been before.

  2. Noooooo. Don’t tell people this! Ugh.

    This was not an intended change. It was a bug that showed up as the new Dev Center rolled out. It’s not been fixed.

    The bug was that *only* for Windows Phone 8.x apps, the Store Association API (which VS uses) was incorrectly populating the PackageMaxArchitectureVersion field, using the last submission’s bundle version (auto-generated date-based number) and not the package number.

    The workaround was just manually change that number back to your previous package version (which you had to do in the middle of the build process as a normal VS build-store-packages operation will update that file from the server as its first step).

    However they’ve fixed the bug, so that isn’t needed any more. It’d be great if you could update this post so that others aren’t misled into thinking they actually have to change their versioning scheme.

Leave a Reply