Common errors for App submission RRS feed

  • General discussion

  • During the progress of publishing and submitting your app to the store, you may meet many errors like package uploading error or WACK test error, in this post it summarizes some common errors and possible solutions for you to refer to, if you have any feedback or questions, please comment out in below.

    Error1: Invalid package family name/package publisher name when uploading package to dashboard

    Error message:

    • Invalid package family name: {yourpackagename}(expected: {yourpackagename})
    • Invalid package publisher name: CN={yourpublishername} (expected: CN={yourpublishername})


    Package display name, Package name, Publisher ID, Publisher display name in the package.appmanifest don’t match the identity in the app identity Page


    What you need to do is get the correct cert details to use within the package.appmanifest manually or the Visual studio can do it automatically by associating the app with Microsoft Store.

    1. In Solution Explorer, right-click your project and then select Store > Associate App with the Store.
    2. In the Associate Your App with the Microsoft Store dialog box, click Next. You'll be prompted to sign in to the Microsoft Store.
    3. On the Sign In page, sign in to the Microsoft Store and then click Next.
    4. On the Select an app name for this package page, select the App Name you have reserved. You can also click Reserve Nameto go to the Microsoft Store to reserve one.
    5. After an app name is selected, click Next.
    6. On the summary page, review the values that you have selected. If it looks good, click Associate. Otherwise, click Previous to go back and fix any errors. Clicking Associate automatically downloads the publisher display name and other values into the app package manifest.

    (From associate your account with Microsoft Store)  

    Error2WACK failed due to the same package already installed 

    Error message: Windows cannot install package abcd.efg_1.1.13.0_neutral_~_ewdfsk6rtuyrt because a different package abcd.efg _1.1.13.0_neutral_~_gm1zauryrt with the same name is already installed. Remove package abcd.efg _1.1.13.0_neutral_~_wegdfrtwetw be installing.


    There was another package with the same package name already installed.


    Step 1. Enter (Win + X, A) then you could open PowerShell as Administrator.

    Step 2: Type the following command.

    > Get-AppxPackage " abcd.efg " -AllUsers | Remove-AppxPackage 

    Error3When you run the WACK on a UWP app that did not go through this compilation process, you will get a not-so-trivial failure. It will look something like:

    • API ExecuteAssembly in uwphost.dll is not supported for this application type. App.exe calls this API.
    • API DllGetActivationFactory in uwphost.dll is not supported for this application type. App.exe has an export that forwards to this API.
    • API OpenSemaphore in ap-ms-win-core-synch-11-1-0.dll is not support for this application type. System.Threading.dll calls this API.
    • API CreateSemaphore in api-ms-win-core-kernel32-legacy-11-1-0.dll is not supported for this application type. System.Threading.dll calls this API.


    The fix is to make sure you are creating your packages properly, and running WACK on the right one. If you follow these packaging guidelines, you should never encounter this issue.

    The problem that users often encounter is that the .NET Native toolchain turns off. For UWP apps, the Release build configuration enables the .NET native toolchain by default, so it is important to test your app with this Release configuration and check that your app behaves as expected. So please pay attention the part:Before packaging your app and check your app as required.

    (From .NET Native – What it means for Universal Windows Platform (UWP) developers)

    Error4The App Pass the local WACK Test but fail on online WACK


    It is a common situation. The local WACK test can only minimize the possibility of failure at the time of submission, and there is a lot of information to fill in in in Dev Center that can lead to failure when you publish app.

    However if we choose the proper way to test package, we can reduce the possibility of failure due to WACK. You could test your package with a low-power computer or the latest the Windows App Certification Kit and Microsoft Store Policy

    The thresholds of WACK based on the performance of a low-power computer. However, as low-power computers evolve, you would better refer to the latest policy and the using most current version of WACK can make sure that your app complies the latest performance requirements. You can get more information about WACK in this official document: Testing with a low-power computer

    Error5Store Certification failure for Cordova UWP app

    Error found: The Application cannot include an ApplicationContentUriRule with 'all' or 'allowForWebOnly' WindowsRuntimeAccess while any of the following capabilities are enabled: enterpriseAuthentication, sharedUserCertificates, musicLibrary, picturesLibrary, videosLibrary, removableStorage, documentLibrary, internetClientServer, privateNetworkClientServer.



    <preference name="WindowsDefaultUriPrefix" value="ms-appx://|ms-appx-web://" />

    This preference identifies whether you want your app to target the local context or web context as its startup URI. When building for Windows 10, the default is the web context  (`ms-appx-web://`).

     In order to have a local-context application that is not impacted by web-context capability restrictions, you must set this preference to `ms-appx://` and not declare any `<allow-navigation>` elements with remote URIs.

    **Valid Values**

    * `ms-appx://` (Default for Windows 8, 8.1): The start page runs in the local context

    * `ms-appx-web://` (Default for Windows 10): The start page runs in the web context

    (From Added support for Windows 10 contains information)

    2. The allow-navigation Element

    <allow-navigation href="XXXXXXXX" />

    This preference identifies origins which will have access to Windows APIs. Effectively, this means that origins which are whitelisted with allow-navigation elements can be top-level navigation targets, and will have full access to Cordova plugins that target Windows.This aligns with the behavior of the allow-navigation element in cordova-plugin-whitelist, but is built into the platform. Both the top-level page, as well as webviews, will have access based on the origin of the URI. It is recommended that, when using this element, that any pages loaded into the frame have a Content Security Policy applied.

    (From What's New in Windows 10 for Cordova)


     In order to have a local-context application that is not impacted by web-context capability restrictions, you must set this preference to `ms-appx://` and not declare any `<allow-navigation>` elements with remote URIs. So delete the element <allow-navigation href=" XXXXXX  " /> . such as Remove the  <allow-navigation href="http://localhost:8080/*" /> in  the  config.xml

    Wednesday, December 12, 2018 2:47 AM