The reason is that Desktop Bridge applications use a restricted capability called
, which allows them to access to all the available Windows resources so that most of the Win32 code will just work as it is. In order to access a restricted capability, you typically need to pass an extra vetting process or reach the Dev Center support team. If your request is approved, the restriction will be unlocked for your account, so that the next time you submit your package you won’t see anymore this error. Specifically for the runFullTurst validation, this process was handled by the Windows AppConsult team. After filling the nomination form linked in the message, one engineer would have reached you back to ask more information about your application and a copy of your package. After that, he would have tested it if it’s compliant from a technical and a Store policy point of view and, if everything is in order, he would have granted you the required permission so that you could complete the submission.
The process helps to ensure that potentially malicious or unstable apps reach the Store but, from a developer point of view, it can introduce some friction. It may take some time, in fact, between the first contact and seeing your app live in the Store:
The engineer must test the package, which may require some time based on the complexity of the application and the current workload
If everything is in order, the engineer can request the unlock of the account, which takes around 1 business day to be processed
Once the developer submits the app on the Dev Center, it must be certified also by the Store team. Currently, all the Desktop Bridge apps are processed only through a manual certification process, which may take up to 5 business days
Since a couple of months the process has radically changed. The Store will now take care of performing all the steps to ensure that your Desktop Bridge application reaches the Store in a timely way if all the technical and policy criteria are satisfied. If you want to publish a Desktop Bridge app, just go to the Dev Center and submit it. From now on, you won’t see anymore an error during the package upload process saying that you don’t have the required permission. The Dev Center will analyze the package and, if it detects that your manifest declares the runFullTrust capability, it will trigger the internal process to evaluate the request.
For you, as a developer, the process will be mostly transparent. It will be exactly like submitting a normal UWP app. The app will go through the certification process and, if everything is in order, the Store will grant you the required permission and make the app generally available to the users. If, instead, the certification team will identify one or more problems, they will fail the certification and you will receive a report with the details. The only difference in the submission process is that, as soon as the Dev Center detects that the manifest of your application declares a restricted capability, it will trigger a new request in the
section, as you can see from the image below:
Since you’re using a restricted capability, you are asked to specify the reason why your application leverage it. By clicking on
, you will see the field below:
In case of Desktop Bridge, it’s enough to specify that your application has been packaged with the Desktop Bridge and you’re good to go. For other restricted capabilities, instead, you will have to provide a more detailed justification so that the certification team can better understand how you’re using the restricted feature.
The outcome of this new approach is that the time to market will be greatly reduced.