Browser extension communicating with UWP app

Question

I need help finding a solution to let a browser extension communicate with my UWP app. Specifically, I need the browser extension to be able to read and write files to the UWP private folder.

I understand that UWP does not directly support Native-Messaging for chromium browsers since the UWP app does not have access to stdin/stdout.

So I think I have only two options to achieve this:

Approach 1: native messaging with a classic desktop win32 app (let's call it the helper) that could exchange data with the UWP app either by reading and writing directly to the UWP private data folder or via AppService

• I know how to create an .exe for the helper (and I do succeed in doing the native messaging protocol) but then I don't know how to distribute it alongside the UWP app
  • if I create a Packager Project containing the UWP and the helper app, then the helper gets packaged, thus runs in a sandbox and can no longer access the stdin/stdout (that's how I understand it, but maybe it does not work for another reason)
  • I've tried to ship the helper as an asset file of the UWP app so it can be executed freely but the helper's .exe does not make it to the final package.
  • Maybe this .exe could be downloaded at runtime ? (Is that fine with Microsoft Store policies and with anti-viruses ?)
• I understand there will also be issues when trying to add a key to the registry to point to the host manifest file since writing to the registry is not allowed for UWP apps. => I have not yet tried to fix this thought because I'm still stuck with the first step. So for my tests I've manually edited the registry.
• I think it would work to ship the helper as an independant app and communicating with the UWP app through AppServices but it would mean the user would have to download the helper and the browser extension (2 seperate downloads in addition to the UWP app) which is not ideal. => If you know a way to install the browser extension with the helper in one download, then that could be a nice solution.

Approach 2: localhost server (with loopback ??)
I have not tried it yet, but I understand there will also be issues with writing to the registry and with having the client on the same machine as the server process.

Do you know how to solve this problem or do you know how to solve any of the subproblems I described in those two approaches ? Thank you in advance for any help you can provide.

Answer 1

Hello, Welcome to Micorosoft Q&A,

If I create a Packager Project containing the UWP and the helper app, then the helper gets packaged, thus runs in a sandbox and can no longer access the stdin/stdout

If you have created desktop extension for UWP app, even the extension's process was managed with UWP main process, it also has permission to access the folder with specific path, it will not be effected by Sandbox. You can do anything that desktop app can do. For more please refer Stefan's blog UWP with Desktop Extension

I've tried to ship the helper as an asset file of the UWP app so it can be executed freely but the helper's .exe does not make it to the final package.

Before windows application package Project template, we use above way to implement full trust launcher that copy the exe file in to the project and add the specific execution path in the package manifest content.

Maybe this .exe could be downloaded at runtime ? (Is that fine with Microsoft Store policies and with anti-viruses ?)

Even you could download exe file, but you also need to add exe file execution path in manifest content, but it does not allow other path except app's installation folder.

Approach 2: localhost server (with loopback ??)

localhost server is approved way to make them commination, for enable loopback please refer this document

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

@Nico Zhu (Shanghai Wicresoft Co,.Ltd.) Thank you very much for taking the time to answer my question.

I was not refering to embeding a desktop extension in my UWP app, but that's interesting. I was talking about embedding a simple .exe file (but maybe that's exactly what a desktop extension is).

What I need is not to be able to access desktop APIs from the UWP app. What I need is to let a browser extension make read and write requests to the UWP private folder. The natural way to do this is to use the native-messaging protocol that lets a browser extension communicate with a desktop app via stdin/stdout (https://developer.chrome.com/docs/apps/nativeMessaging/).

The problem is that UWP processes cannot access stdin/stdout, hence the idea of the embeded win32 app. So this embeded win32 app should be launched by the browser extension, not by the UWP app. So I tried to package both the UWP and the win32 app in the same bundle then point the browser extension towards the packaged win32 app, but then the native-messaging protocol stopped working (even if it works with the same .exe that is not packaged with the UWP app), as if the stdin/stdout were no longer available. I believe that the packaged win32 app is also launched inside a UWP process hence does not have access to stdin/stdout. But maybe I just did something wrong.

I dug into using a localhost server, but loopback seems to be made exclusively for IoT. Hence, the server and client (in this case the browser extension) cannot be on the same machine... so I believe it won't work. => is it possible to let a UWP open a localhost server that can be accessed on the same machine ?

Answer 3

I also started developing a universal application and I need to pair it with a browser extension. I couldn't find anything useful anywhere on the internet. Is there any working example of how to pass data from a browser through an extension in a universal app?
Microsoft has several articles about the Edge extension but no any information on the implementation of native messaging on the Windows apps and especially UWP.
It looks like on the "legacy Edge" only UWP could communicate with browsers but now this has been cancelld?

I will be grateful if you help clarify the possibilities of implementing native messaging in universal applications.