UWP with Desktop Extension – Part 4


If you haven’t read part 1 , part 2 and part 3 of this series yet, please start there first. In this final part I will explain how to submit a UWP with desktop extension to the Microsoft Store.

The .appxupload File

The Store accepts .appx, .appxbundle and .appxupload files (as well as .xap files for Silverligt phone apps). For UWP apps with desktop extension components the best way to go is the .appxupload file. The VS Packaging Project produces this file for you and ensures it includes all the right binaries, assets and symbols. It’s an important thing to remember to create the .appxupload off the packaging project, not the UWP project in your solution. The latter will not be valid for Store submission.

To produce the .appxupload file, right-click on the packaging project in Solution Explorer, and select “Create App Packages …”


Now follow the instructions in the wizard and select the appropriate options like version number, architecture etc.


Once you hit “Create”, VS will produce the .appxupload file as well as test packages that can be used for local testing. At this point it is recommended to perform the following test activities:

  1. Launch the Windows App Certification Kit (from the dialog) to run all the applicable certification tests. Any failures in the mandatory certification tests will block your Store submission, so you will want to get on top of those right away. Note that there are also optional tests in the suite. Those point to potential problems in the app that may lead to problems on certain devices/configurations. Those failures won’t block the submission, but are rather warnings for you to take a look and double-check. A typical optional failure we are seeing with desktop extensions is the 4.2 Blocked Executable test. This test warns you if it detects code that potentially launches unsigned EXEs or utilities such as PowerShell, cmd.exe or reg.exe, as those are not allowed in Windows 10 S mode. Note that these may be false positives and won’t block your Store submission.
  2. Perform a final test pass of the packaged app, outside of Visual Studio. What I typically do is copy the *_Test folder under AppPackages to a clean test machine or VM (i.e. one that doesn’t have a VS development environment) and run the Add-AppDevpackage powershell script to install it in a way that is nearly identical to how your customers will install it from the Store. Then sanity check all important features of your app, including your desktop extension.



Adding ARM Configuration

If you are targeting Mobile with your UWP, you will need to provide ARM packages. In the current build of Visual Studio 2017 (Update 15.7) the packaging project does not create ARM packages by default. You will have to edit the .wapproj and add ARM support explicitly:


Now replace “AnyCPU” with “ARM”, as you won’t need the neutral configuration for the packaging project:

<ProjectConfiguration Include="Debug|AnyCPUARM">
<ProjectConfiguration Include="Release|AnyCPUARM">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPUARM'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPUARM'">

Once you have done those edits save the changes and reload the full solution (not just the project). Now you are set for building and submitting ARM packages (alongside your x86 and/or x64 packages).

It’s a good idea at this point to double-check the configuration properties in the solution for ARM. It should look like this:



Requesting ‘runFullTrust’ Approval

If you are submitting your UWP with desktop extension for the first time you will receive an error because you don’t have permission to submit apps with the ‘runFullTrust’ capability. To request access you are redirected to this form:

Once you have submitted your info a Microsoft engineer will contact you and work with you through the onboarding process for your app. Once that is done you will be able to submit your app and any future updates just like for any other Windows Store application. We are working on making this initial onboarding process smoother and I appreciate your feedback. If you see any hiccups or delays going through the process please don’t hesitate to contact me and I will do my best to get you unblocked.

In Closing

This is it for my 4-part quick tutorial on how to make your UWP apps even better on PC by lighting up desktop extensions. What’s next? I have started to put together a number of concrete examples of activities that Windows Desktop apps typically need to perform outside of the sandbox, like integrating with legacy systems in LOB scenarios. Those I will blog about next and publish the samples in this repo – stay tuned for more on this coming soon …




  1. Hey Stefan,
    thank you for this UWP/Desktop-tutorial. I’m a desktop developer since many years so UWP with all his restrictions is not easy. I wrote a small UWP app with navigation and i have some memory leaks there. i found out that all windows apps have these memory leaks (e.g. Windows 10 settings app). Is this is basic problem? Are there any fixes?
    Greetings from Berlin


    1. Hi Nico,

      memory leaks/bloat during frame navigation may happen for a number of reasons: there could be bugs in the app code, bugs in a framework the app is using or bugs in the operating system. We have eliminated a number of OS bugs in this space in the past, but I am aware of one bug that still remains in 1803 and still needs to get fixed in a new update. That bug is causing about ~1.5kb getting leaked per navigation. If you are seeing leaks larger than that, and especially if you are seeing leaks proportional to the size of your frame’s content then there are likely additional bugs in app/framework code that contribute here. In that case you should use a memory profiling tool to get to the bottom of what is being leaked and who is holding on to those objects.

      Hope this help. Gruss zurueck nach Berlin!



    1. Hi Uros,

      this field isn’t really a requirement anymore. This form will go away shortly. In fact you should be able to submit without the form and will then be routed through the new onboarding process. Let me know if you hit any problems with that.



  2. Thanks for the blog!
    I am currently investigating the possibility to develop a really simple FolderBackup app that could be of interest for people that have problems with using/understanding built-in Windows backup features and/or currently available external solutions.
    Because of background execution restrictions in pure UWP I will probably have to use Desktop Bridge and launch a Win32 task to register on the Task Scheduler.

    2 questions:
    – Would such an app pass approval?
    – Is there anything in Desktop Bridge that would allow me to deregister a possible task in the scheduler when the app is uninstalled? I am thinking of using the VS Project Packaging template (no special installer/uninstaller).


    1. We would allow such as an app in Store. Not sure you necessarily need the task scheduler though. How would you use it?

      Note that we also have ‘extendedBackgroundTaskTime’ capability for UWP that let’s you remove those restrictions. Furthermore, you can use UWP background tasks and launch a Win32 process from there if needed for certain operations.


      1. Thanks for the prompt feedback.

        The reason for not using ‘extendedBackgroundTaskTime’ is that the documentation says that you can’t put the app in the store if you use that capability (See https://docs.microsoft.com/en-us/windows/uwp/launch-resume/run-in-the-background-indefinetly ).

        The desktop bridge with scheduler approach would give me a couple of things out of the box:
        – Backup can be scheduled at any point in time configured by the user.
        – If the backup task is missed, the scheduler takes care of launching the task when the computer is rebooted.
        – Minor: a win32 task can also copy hidden files.

        Not sure how I could solve the issue of missed backups when using a pure UWP approach. In that case I probably have to configure the app to automatically run at boot. That would be ok if it not that some people will probably don’t like the idea that the app shows up on the taskbar (although minimized). For me personally that would be ok since it shows the user explicitly that something is going on (instead of hiding all of this in the systray).

        But, as I mentioned before, not being able to publish to the store is what stopped me looking further into pure UWP.


  3. Hi guys. I want to develop an app for desktop only which will make backup and restore of files. will be a desktop app only but i want to uploaded to Microsoft store and sell it form there. I know that uwp need special permissions as they run on sandbox in comparison to standalone apps. Do you think is possible to have this app on store? Regards


      1. Hi Stefan, thank you for your answer. I am not such a technical person ( I am only doing research now) , but with this app that I described, as the permissions in uwp are limited, the user could for example back up a partition, windows files, use external drives?


  4. Hi Stefan,

    One more question:

    Can building an appxbundle/appxupload be automated through msbuild, for instance?

    For the simple UWP app (without Desktop Extension) I’m able to this with the following command:

    msbuild UWP.sln /p:Configuration=Release;AppxBundle=Always;AppxBundlePlatforms=”x86|x64|ARM”;UapAppxPackageBuildMode=StoreUpload

    However, when I try it on Package.wapproj I’ve got a bunch of errors.
    For instance, although Package project has a certificate, UWP project also demands one (why?), when I workaround that problem, msbuild demands a build.appxrecipe from bin/Debug, although I’m building Release etc. Have you experienced something like this?
    Any advice?

    Any answer is appreciated.

    P.S. Never had this sort of problems without Desktop Extension/Package.

    Regards and thanks,


      1. Hi Uros,

        sorry for the late reply, I missed your previous message while I was offline on vacation. In theory it should just work the same way as a plain UWP app project. I would suggest you post this issue as question on Stackoverflow and then we will have someone from the tooling team take a look at those errors.



  5. Hi Stefan,

    Great tutorial! Desktop Bridge has opened up wonderful possibilities for my 4+ year old Windows Store app and my users are very pleased.

    I’m currently extending my WPF Desktop bridge app to have Modern UI components. My WPF will (install and) launch the UWP App in my debugged project no problem, but when I package the desktop app, and run the powershell script on a different machine, the app cannot find the UWP app to launch. It doesn’t seem to be installed, even though I referenced it in my Packaging solution. Am I missing something? I’m only creating x86 packages so does that have anything to do with my issue?



      1. I added a protocol to the UWP project and called it using Launcher.LaunchUriAsync() from the WPF app. (Following this tutorial: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-extend)

        How do I verify that the UWP app is in my package? I see the .appxupload has not changed in size both before and after I added the reference to the UWP project in my Packaging solution so it doesn’t seem like the the packaging wizard is doing anything with the UWP reference.


      2. After installing your test package you look at the installation folder to see if everything is there.

        Thinking about this some more, you are possibly just missing to declare a dependency in the appxmanifest that is required for the UWP. On your developer machine it works because all the dependencies are already installed as part of Visual Studio.


    1. Do you have a reference to the specific issue you are referring to? I am aware of a navigation leak bug being fixed for 1809, but I can’t say for sure we are talking about the same issue.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s