9

We are fixing to re-architect an application and are debating whether or not it is possible to use UWP instead of an ordinary WPF application.

Our application needs the ability the access the entire filesystem and all system resources. This is an issue since UWP apps are sandboxed. However, we are trying to bypass that issue by trying to approach it in this manner:

  • Windows Service -> Running on the system at all times. This will host the core functionality when it comes to accessing and modifying system resources.

  • UWP Application -> Since UWP is sandboxed, the UWP app will forward all system requests to the Windows Service, which will do all of the brunt work and just return the output.

We can simply do this in WPF, but we would like to use UWP in order to utilize some new Windows 10 core features WPF is lacking such as live tiles and Cortana.

Do you think our approach is feasible? One of our uncertainties is how we can get the UWP app to communicate with the Windows Service- we've looked into things like SignalR and the Desktop Bridge but are unsure which may be the best approach for our scenario.

Thanks!

Stefan Wick MSFT
  • 12,864
  • 1
  • 26
  • 47
user3397214
  • 157
  • 3
  • 9

3 Answers3

4

Do you think our approach is feasible?

We cannot directly consume a Windows Service in an UWP app. In order to make the IPC between Win32 app and UWP app, what may help here is using the new Capability <rescap:Capability Name="runFullTrust" />, and it enable the Win32 app which is launched by the FullTrustProcessLauncher API to achieve the uplevel app security context to consume WinRT APIs. But as you see the rescap here, it means this UWP app cannot be published in Store.

You can refer to the official AppService Bridge Sample. You can try to firstly create a traditional desktop app which consume App service (which can communicate with WPF and UWP app, not traditional Windows service) and use WinRT APIs, after building this app (don't run it), a .exe file will be generated. But this app cannot run since it uses WinRT API, then you can create your UWP app to make this desktop app executable.

we've looked into things like SignalR and the Desktop Bridge but are unsure which may be the best approach for our scenario.

So I think the Desktop Bridge may be the best approach here.

Grace Feng
  • 15,906
  • 2
  • 19
  • 40
  • 1
    The issue with AppServices is that it can't trigger an event as far as i know. You can only call it from UWP which return me to the original issue that the UWP App should be in the foreground or uses background process which has a limit of 15 mins minimum time trigger. My purpose of creating the Windows Service in the first place is to overcome this limit. Can you please suggest a solution to this problem – Ali123 Sep 22 '19 at 10:51
0

You can check my sample code: https://github.com/manupstairs/UWPWithWCFSample

I think WCF is the right answer.

For duplex binding, check this one: https://github.com/manupstairs/UWPwithDuplexWCF

One step closer to submit one APPX to MS Store. You need desktopbridge tech. UWP UI part and WCF service host in console. We can combine them into one APPX.

Capability "runFullTrust" is necessary. https://developer.microsoft.com/en-us/windows/bridges/desktop/

Xing Zheng
  • 1
0

I just made a library for IPC between UWP and .Net Framework Windows Service through shared memory. It is not necessary to use Full Trust capability or configure network loopback rules. When you create shared objects, just explicitly set access rules and add your UWP app to ACL, and it will be able to open global named Mutex / Semaphore / Event and memory mapped files created by Windows Service.

GitHub repository with source code, tools and samples

Nuget package

Oleg Mikhailov
  • 209
  • 1
  • 7