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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.