“Package acceptance validation error” when you submit a UWP + Desktop Bridge app on the Store

Update on 20th March 2018: this blog post isn’t valid anymore, since the Dev Center team has fixed the issue on his side. As such, you can just submit an app package generated by Visual Studio without encountering anymore the error described in this post.

On this blog we have covered a while ago the Desktop Bridge scenario called Migrate. With this approach, you can develop a full Universal Windows Platform app that, only when it runs on a desktop machine, it’s capable of invoking and communicating with a classic Win32 process. It’s a great technique to reuse some of the business logic you may have already created or to leverage some APIs which don’t have a counterpart yet in the Universal Windows Platform.

This is, usually, how an application in such a stage looks like:


It’s a regular UWP project with a folder (in this case, we’ve called it Win32) which contains all the traditional Win32 executables and DLLs. Thanks to an extension declared in the manifest and a special API which belongs to the Desktop Extension SDK, you’re able to invoke this process from the UWP app. Additionally, using App Services, you are able to implement a communication channel which allows to share data back and forth between the two worlds. I suggest you to read the original post if you want to know all the implementation details.

In this post I would like to focus on an error you might face when you try to submit such an application on the Store.

First, let me clarify one thing because I saw many developers making this mistake. If you have a UWP application with a Win32 component, you don’t need to use the Windows Application Packaging Project. This new template, included starting from Visual Studio 2017 Update 4, is great when the starting point is a Win32 app that you want to package with a modern deployment technology or to extend using features coming from the UWP world (like APIs or components). In our scenario, instead, the starting point is a UWP app, so the Windows Application Packaging Project isn’t needed. You just need to make sure that, inside the package, you’re going to create, you will include also the Win32 executables and libraries, in addition to the UWP components.

Now let’s talk about the error. Being a regular UWP application, creating a package for Store submission is an easy process. Just right click on the project, choose Store –> Create app packages and follow the wizard. At the end, you will get a folder with a file with the .appxupload extension, which is the one you’re going to upload during the submission process.

Unfortunately, when you’ll try to do it, you’ll face the following error:

Package acceptance validation error: Apps converted with the Desktop Bridge and that require the .NET Native framework must be pre-compiled by the .NET Native tool chain

This is a known issue of the Dev Center, which is being worked on and it will be addressed in the near future. In the meantime, here is the workaround to complete the submission process:

  1. Right click on the project, choose Store –> Associate App with the Store and make sure to choose the name you have reserved on the Dev Center. This way, the manifest will be automatically pre populated with all the right info (app name, publisher, etc.)
  2. Generate the package with Visual Studio as usual, by right clicking on the project and choosing Store –> Create app package. This will produce both an .appxupload file and a folder with the _Test suffix.
  3. Ignore the .appxupload file produced in the steps above
  4. Create a new zip file and add the .appxysym files and the .appxbundle file from the _Test folder mentioned above.
  5. Rename the file extension from .zip to .appxupload

Now you have a new .appxupload file that you’ll be able to submit on the Dev Center. This time it will be accepted and you will be able to finish the process and submit the app for the certification.

This problem can occur also if you want to submit an Edge extension with a Desktop Bridge component, as my colleague Raiford has described in the following post.

Of course, remember that also these apps make use of the runFullTrust capability and, as such, they have to go through an extra vetting before reaching the Store. If you aren’t working yet with a Windows AppConsult engineer, you can nominate your application at https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge You will be contacted back by one engineer to move on the process.

Happy packaging!

Comments (8)

  1. CMak3 says:

    Hi there,

    I have a UWP app that contains a traditional Win32 executable as well just like the example you have given here. My account also has the proper permissions to allow apps with the “FullTrust” capability. About two weeks ago, I followed these steps exactly to upload a package of my app and it all worked great.

    Now this week, I am trying to upload a new update and I followed the same steps but I run into another error: “Package acceptance validation error: You cannot submit pre-compiled .NET Native packages. Please upload the Store appxupload file and try again.”

    I am unsure how to resolve this issue now. Any ideas? I did also update Visual Studio to version 15.6.2 if that makes a difference.


    1. Hello,
      the problem you’re seeing is the one I’ve described in this post you have just commented 🙂
      If you read it through, you’ll find all the details on how to solve it and get a package that you can submit it on the Store.

      Let me know if you’re still blocked!

      1. CMak3 says:

        Hi Matteo,

        Thanks for responding.

        The error that I am seeing is different from the one you describe in your post. My error states “You cannot submit pre-compiled .NET Native packages” while the error you describe in your post states “Apps converted with the Desktop Bridge and that require the .NET Native framework must be pre-compiled by the .NET Native tool chain”. So I am trying to submit pre-compiled packages, but it’s not letting me for whatever reason.

        I submitted an update two weeks ago with the steps that you provided on how to package the app and it worked. But this week, I packaged the app in the SAME way as you have described in your post, but now I am getting an error.

        Anything you can think of why this would be the case?

        1. Ah ok, sorry for the misunderstanding.
          When you have created the packages for the Store using the Visual Studio wizard, did you choose Release as configuration? Can you please verify, in the UWP project, that Release mode the .NET Native compilation is enabled for the Release configuration?


          1. CMak3 says:

            Yes, I go through the “Store” -> “Create App Packages” option in Visual Studio and the Release configuration is selected for all three architectures. The “Compile with .NET Native tool chain” is also enabled for the Release configuration under my UWP app Build properties.

            Like I said, this worked the last time so I don’t understand why now it wouldn’t. Seems like something as changed on the Dev Center side. But anyway, let me know if you have any other ideas. Thanks again for your responses and help. I appreciate it very much.

          2. I apologize for all the questions but I’m trying to pin down all the possible issues.
            So, to recap:

            1) You have a UWP project which contains one or more Win32 processes / DLLs
            2) You create the package using the Store menu in Visual Studio
            3) At the end of the process, you follow the steps described in this post to generate a new .appxupload file
            4) Even with the newly manually generated .appxupload file, you get the issue you have reported while trying to upload the package on the Dev Center

            Is my understanding correct?


          3. CMak3 says:

            No problem Matteo. I don’t mind clarifying.

            Yes, the steps you listed is exactly what is happening. My manually created “appxupload” contains the “.appxsym” and “.appxbundle” files just like it is stated in your article.

          4. Can you reach me by mail at name.surname@microsoft.com (replace name.surname with my full name and surname)? I need to ask some more details offline.


Skip to main content