stefanwick

UWP with Desktop Extension – Part 4

extensions4

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 …”

screenshot1

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

screenshot2

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.

screenshot3

 

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:

screenshot4

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

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

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:

screenshot5

 

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:
https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge

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 …

https://github.com/StefanWickDev/ExtensionGallery

Posted in UWP Features & SamplesTagged , , , 39 Comments

39 thoughts on “UWP with Desktop Extension – Part 4”

  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
    Nico

    Like

    Reply

    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!

      Stefan

      Like

      Reply

    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.

      Thanks,
      Stefan

      Like

      Reply

  3. 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).

    Like

    Reply

    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.

      Like

      Reply

      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.

        Like

  4. 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

    Like

    Reply

      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?

        Like

  6. 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,
    Uros

    Like

    Reply

      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.

        Thanks,
        Stefan

        Like

  7. 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?

    Thanks!

    Like

    Reply

      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.

        Like

      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.

        Like

    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.

      Like

      Reply

  9. Hi Stefan,

    Our dev team is proposing to integrate an UWP solution with a Win32 app. But I have one doubt. Can a UWP app handle this workflow:

    UWP -> start Win32 -> Spawn another process (inside package as an Asset)

    I did an small package to test this workflow and I’m not able to Spawn another process from the Win32 app. Maybe this is restricted on UWP apps?

    I appreciate any help you can give me

    Thanks!

    Like

    Reply

      1. Thanks! Stefan I got it working. I got one last question. Let me give some context:
        We currently have a win32 app that is a local TCP/IP REST server. We use it as a backend for some of our applications. Now another team has an UWP app and would like to use this backend.
        I think we could package our win32 app as an UWP app, package all of this inside the other team UWP app, and then use loopbackaccessrules to avoid network isolation.
        I would do an small feasibility test but still I would really value your opinion. Is this possible?
        PD: If possible we would like to avoid rewrite the REST API as an AppService.
        Best regards and thanks!!
        Some links with documentation:
        https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap4-loopbackaccessrules
        https://social.msdn.microsoft.com/Forums/windowsapps/en-US/0cdb98ca-e872-4b61-9506-881acdf5e03b/uwpdesktopbridge-can-quotuap4loopbackaccessrulesquot-be-used-to-allow-tcp-communication?forum=wpdevelop

        Like

      2. Yes, this should work. Let me know if you run into any issues. Caveat is that I have never played with the loopbackaccessrules myself, but this would certainly make a good future blog post.

        Like

  10. I can take my current UWP appx file and install it on another Windows 10 machine just by double clicking the appx file in Windows Explorer. In other words I don’t use the Windows Store for distribution/installation.
    I am now wanting to add a Desktop Extension to my UWP project. Reading your articles, my understanding is that the bundle created from the Packaging project must be uploaded to the Windows Store and verified by a Microsoft engineer before it can be distributed.
    Is there any way to avoid using the Windows Store for distributing UWP apps that include Desktop Extensions?

    Like

    Reply

    1. No need to submit it to the Store. You can distribute the package yourself also with desktop extensions. Only requirement is that you sign your package with a certificate that is trusted on the target machines (which is true for packages with or without desktop extensions).

      Like

      Reply

      1. Thanks Stefan,

        Just tried this. One problem worth mentioning is my UWP app is running full screen via appView.TryEnterFullScreenMode().

        When I launch my trusted Win32 app, it starts running behind the UWP app. If I call appView.ExitFullScreenMode prior to launching Win32 app, I see the Win32 app appear over the UWP app.

        But I don’t want the UWP to be displayed in a window.

        Is there any way I can hide the UWP app prior to running the trusted app, and then reshow the UWP app after the trusted app is closed?

        Like

      2. You can make your Win32 app the entry point of your package. This way it gets launch first, then you can trigger the UWP app launch from there.

        Like

      3. Great, that is exactly what I need, but struggling to implement.
        Can you provide example syntax of a typical Win32 app entry point?
        Also, how would I subsequently launch the UWP app from the Win32 app?

        Like

      4. Unfortunately this scenario isn’t very well supported by Visual Studio, so it will require a number of tedious steps to get this set up. I don’t have a sample handy right now, but essentially it goes like this:

        1) In your solution have (a) Packaging project, (b) Win32 project and (c) UWP project
        2) Reference both the Win32 and the UWP project as applications of the packaging project
        3) Temporarily (!) set the UWP as entrypoint and deploy the packaging project
        4) Find the appxmanifest.xml file in the APPX folder of the build output
        5) copy the … element from the manifest and save it somewhere
        6) now switch the entrypoint to be your Win32 app which is what you really want
        7) edit Package.appxmanifest in the packaging project and insert the saved element (so you have two app elements now)
        8) update the Id property so it is unique, and add AppListEntry=’none’ to the VisualElements element (this is to hide the UWP from the app list)
        9) now you can redeploy the package and your Win32 app is the entrypoint, with the UWP still included

        To launch the UWP app from the Win32 you can use this API sequence:
        Get the current package: https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.package.current
        Get the app list entries: https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.package.getapplistentriesasync
        Launch the (hidden) UWP app list entry: https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.core.applistentry.launchasync

        Like

      5. OK. Doesn’t sound too tedious. One last question.
        Step 6) What is the syntax for the entry point of my Win32 WinForms app. Is something like ‘MyApp.WinMain’ or ‘MyApp.Form1’ ?

        Like

      6. The entrypoint is simply a generic “Windows.FullTrustApplication”, but don’t worry about that part as VS will set this up for you correctly in step 9. If you are curious what a manifest would roughly look like, take a look here:
        https://github.com/microsoft/DesktopBridgeToUWP-Samples/blob/master/Samples/WinformsAppService/TestClient/Package.appxmanifest

        Don’t use this sample as starting point for your project though. It’s different and outdated in a couple of ways. Sharing the link here only to give you a glimpse of what your manifest should look like.

        Like

  11. Hi,
    Thank you for writing how to use UWP with desktop apps.

    Any chance to get the missing bits:
    Use non Net Standard 2.0 nugest and technologies, like Linq2SQL ?
    How to deploy app using network share (company network) like using ClickOnce? Deploy – > user click setup, On next publish -> app on user’s pc auto updates?
    Optimize for Windows 10 (native compile, remove ARM, etc?)
    Be able to use old Windows 10, like 16xxx ?

    AppService seems to be slowing down working as a proxy to Linq2SQL db calls ?
    Best regards

    Like

    Reply

    1. Missed the part – how to re-use loggers, like log4net, etc to log to file outside App folder (Storage)?

      Like

      Reply

      1. Hi – if you are asking for blog posts on those topics, I am afraid I won’t be able to commit to writing those. I no longer work in Windows and my focus and priorities have shifted to other technologies at this point. You should be able to find answers to your questions on official sites like docs.microsoft.com & techcommunity.microsoft.com and get remaining questions answered on stackoverflow.com & social.msdn.microsoft.com/Forums/

        Liked by 1 person

  12. Hi,

    I have followed your tutorial and added FullTrust support and is in the process of updating my Windows Store app.

    1.
    Is the following link still available?
    https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge

    It appears to redirect me to
    https://developer.microsoft.com/en-us/windows/

    2.
    When building App packages in VS2019, I can build the x86 one successfully. But building for x64 and ARM gives me

    There was a mismatch between the processor architecture of the project being built “AMD64” and the processor architecture of the reference “C:\vc5\barcodenlabel\NativeManager\bin\x86\Release\netcoreapp3.1\win-x86\NativeManager.dll”, “x86”.
    This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

    Any ideas what I can do? Or can I just submit an x86 package?

    Like

    Reply

    1. The docs have moved to the MSIX part of the Windows developer docs:
      https://docs.microsoft.com/en-us/windows/msix/

      I won’t be able to help you with your runtime failure. I have moved on to a different area since 2018. I recommend you post your question on stackoverflow and tag it with ‘uwp’ and ‘desktop-bridge’. This way folks from the right team will pick it up and help you find a solution.

      Like

      Reply

Leave a reply to Allen Cancel reply