How can we improve the Microsoft Edge developer experience?

MS Edge Extension with Native Messaging on Desktop PC - Run UWP App in Background / no UI

We have a classic desktop application on Windows which needs to communicate with the web browsers. Therefore we created web browser extensions and use the native messaging technology to pass messages between the JavaScript on a web page and the native desktop application. This way of communication is currently supported in Google Chrome, Mozilla Firefox and Opera. Now we want to perform the same task in Microsoft Edge. But unfortunately Microsoft Edge supports native messaging in a different way the other browsers do. In Chrome/Firefox/Opera simply a serialized JSON string can be passed to a native messaging host application via stdin/stdout.

As Microsoft Edge is a Universal Windows Platform Application it only supports communicating with another UWP App via AppService (and further communicating with our classic desktop application via FullTrustProcess). Our classic desktop app cannot be converted to an UWP app for many reasons. Basically this is no problem, but there are some issues I currently don't know how to solve:

UWP Apps seem to require a user interface. But the extension's purpose is only the communication, there is no UI intended.

So I could display some information about the UWP App / Edge Extension when the user opens the UWP app, but if the user closes the App (e.g. by clicking the (X) button), the UWP app process is killed by the system. If this happens during a communication process, the native messaging communication is interrupted and the user will receive an error. So far I have not found a way to avoid this. When Microsoft Edge launches the UWP App (initiated by "runtime.connectNative" in the extension's background JavaScript code) it runs in background mode and will be terminated if Microsoft Edge exits which is OK. But if the user opens the App (e.g. via start menu), the process for the App is reused and it is now running in foreground mode. And then if the App UI is closed by the user, the process which initially was started by Microsoft Edge will be terminated. I have looked at the official "ExtendedExecution" example from Microsoft, but this behaves the same way.

Is there any way to send the UWP App to background mode execution instead of termination if the user closes the UI of the App? So that the App can continue running in background mode as it did before?
Or is there any way to hide the UI in the OnLaunched event (e.g. then our classic desktop app will be opened, and the user will now not be able to manually close the UWP app any more)?
Probably I can find the HWND of the UWP app from our native desktop app and perform some ugly hacks with it, but I definitely want to avoid this.

I have found out, that there is a way to narrow the user's possibility to launch the application by setting AppListEntry="none" in the manifest. So the user cannot start the application from menu anymore.
But the user still can launch the application e.g. by klicking the "Launch" button after installing the app (e.g. side loaded from the appx package).

Any suggestions?

Regards, Dominik

8 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Dominik shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    2 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Kuldeep Desai commented  ·   ·  Flag as inappropriate

        Hi, We developed something very similar recently. We have the UWP running always, but instead of console app, I am using windows app, and that will automatically run UWP in background and no UI. If there is no need for your user to view UI, you can run something similar, else if that is not the case you can subscribe to disconnect event and show appropriate message to user to run the extension again.

      • rram commented  ·   ·  Flag as inappropriate

        Hi Dominik, I have nothing to share about the solution to your problem.
        We are trying to develop something similar to your extension design and want to support windows 10 anniversary edition. So, want to know if you were able to deploy the native messaging extension on windows 10 anniversary update (version 1607) or only after windows 10 creators update ??

      Feedback and Knowledge Base