Closed tim-weis closed 1 year ago
Through experience publishing several apps to the Windows Store I have found that AppX manifests without PhoneIdentity
tags are perfectly acceptable by the system. (I never include them in my source AppX manifests, and I have successfully published two apps — one UWP, one Desktop Bridge — without any issues.) If the Store requires them internally, it may well just add them automatically; I of course cannot say. My advise is just to ignore the PhoneIdentity
tag and push on. Hope this helps!
@wjk: The PhoneIdentity
element is indeed optional in the schema reference for the Package. If I omit it, however, the build fails:
error APPX1673: App manifest is missing required element 'PhoneIdentity'.
The full error message is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets(2269,5): error APPX1673: App manifest is missing required element 'PhoneIdentity'.
This is using Visual Studio 2017 15.6.7, compiling a native UWP application.
I don't know, why the build tool insists, that the element were required, though the mismatch between the schema reference and the build tools with respect to existence of the PhoneIdentity
element could be an indication, that there is an issue with the build tools for native targets.
But even in that case the documentation could benefit from explicitly pointing out under which conditions the PhoneIdentity
is semantically required.
In that case, I would simply recommend using new, random GUIDs for both attributes. AFAICT you only need to worry about the values if you are upgrading a Windows Phone 8 app. Since you're not, I don't think the values will mean anything.
@wjk: I'm currently using a random GUID for the PhoneProductId
, and a null GUID for the PhonePublisherId
. Using a null GUID for both attributes did compile, but failed deployment to a Windows 10 Mobile device. Since I haven't published the application yet, I'm not sure what to expect when using a random GUID for the PhonePublisherId
. After all, that's a valid ID, albeit for an unregistered publisher. A null GUID, on the other hand, is easily identifiable as an invalid ID.
At any rate, the sole purpose of documentation is to take out the guesswork. This is a public interface and we can expect it to be sufficiently documented. I can't phrase it any better, than Marsellus Wallace once did:
We don't want to think. We want to know.
In the case where the TargetDeviceFamily
does not include Windows.Phone (e.g. it is Windows.Desktop
only), it would be good to have guidance what values should be included here (i.e. null/random GUID). As @tim-weis says, Visual Studio 2017 won't compile without it.
This is still an issue with a newly-written WinUI 3 desktop app in 2022. What's going on?
Just finished a small WinUI3 desktop app (my first experiment) which works fine both during debugging and as a sideload. Attempting to have it submitted to the Microsoft Store, though, is pure masochism! All kinds of unexplainable and unjustified errors (including this one about the PhoneIdentity missing) make the whole experience a huge frustration. I'm using VS2022 17.2.1 and I can't understand why this issue is open since 2018?! If MS wasn't ready to release WinUI3 because it is far from complete, why did they?
Just came across this in my first attempt at a WinUI3 application that I need to submit to the Store to continue my developer program enrollment. Being hit by undocumented package errors is not an ideal scenario to be in. Should WinUI 3 have been released in this current state, I mean let's not get started with the multi-window issues.
Is there a good example of an App Manifest that can be trusted to meet the definition of good someone could link me to?
It is almost 2023. This problem has not been solved yet. Microsoft's work efficiency is worrying
For winui3 app: If you chose Screen rotation in Package.appxmanifest,it will generate a "PhoneProductId" in this file. I cancel chosed Screen rotation item and fixed this issue.
Hello to everyone on this thread. Sorry for the long delay in addressing this issue. There are a couple of different things going on here. First, the PhoneProductId and PhonePublisherId are required for all apps, but their values aren't used or validated. Second, these values are supposed to be set in all project templates and it was a bug that they were not included in some templates that shipped. The fix for this has been checked in and so, moving forward, hopefully developers won't need to worry about manually setting these values. Since this repo is focused on documentation issues, the documentation has been updated with the following remark which specifies that the entries aren't validated. It also gives some guidance for people who have found themselves with templates that don't have the default values set.
"For apps that are not migrating from a mobile version, the PhoneProductId and PhonePublisherId are required for Store submission but are not validated. For project types that require the PhoneIdentity element, the Visual Studio project templates should include placeholder values. If you created a project from a template that does not include these values, you can specify any GUID for PhoneProductId and the value "00000000-0000-0000-0000-000000000000" for PhonePublisherID."
The URL for the page has also been changes since this issue was first opened.
https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-mp-phoneidentity
Again, apologies for the slow response here. And thanks for providing this valuable feedback.
@drewbatgit Could you please specify where to add the Phone Ids? What VS says does not make sense. I'm surprised that publishing a WinUI 3 app is affected with a 2018 bug.
@ArchieCoder - I'm sorry this issue is taking so much of your time. The element, when it is required, goes directly under the Package element. We try to convey that in the docs with the element hierarchy at the top of the page - but that's less obvious when the tree is only one level deep. Here is a new UWP app project that I just made:
But I'm not sure that's the issue here. Re-reading the email from the feature team about the bug fix, it was to unblock Store submission and was not something that would cause a WinUI project to not build. We don't normally try to do technical support in the documentation repo, but if you could answer a couple of questions, I'll try to find an answer for you:
@drewbatgit Thanks to @npbcts, the trick to check screen rotation helped to know where the Ids go (only PhoneProductId was added, I added manually PhonePublisherId).
1- I used the latest WinAppSDK: 1.2.230118.102. I used Template Studio. 2- I created the app yesterday with Template Studio. Even a blank new app without Template Studio has the bug. HUGE FLAG! 3- Only when creating the package for the store. 4- I'm okay now, but if you need it Package.appxmanifest.txt
FYI, I'm a professional working full time with UWP since day 1. I was MVP Windev for 9 years. Seeing these bugs are not going to help new developers to use WinAppSDK.
@ArchieCoder I have a PR out in Template Studio with the fix. It will become available with the next release of it. https://github.com/microsoft/TemplateStudio/pull/4624
@pratikone Thanks for the fix, it will help others to submit their app to the Microsoft Store with more ease. FYI, the bug is also there for a blank app (non-Template Studio) offered by VS.
It has been fixed for WinUI 3 apps (non template studio). Did you mean their template in VS ?
The documentation explains, what values to choose for the
PhoneProductId
andPhonePublisherId
, in case the package is an update to a Windows Phone app. It does not explain, what values to use in case the app is not an update, but rather a new UWP app.This information is needed by developers, that cannot use the New Project templates in Visual Studio, authors of Visual Studio extensions, or vendors of project generators (such as CMake).
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.