120

In a situation where you have the UI frontend built using the new Metro style of apps for windows 8, and would like it to communicate with a .NET application running on the desktop on the same local machine (e.g. a windows service app).

What forms of interprocess communication are available between the metro app and the desktop app?

Thanks to Pavel Minaev of the Visual Studio team, who has provided some initial info here in a comment, quoted:

According to Martyn Lovell, there isn't any deliberate mechanism for that, and some that could be used for it are intentionally restricted. Named pipes aren't there, for example, nor are memory mapped files. There are sockets (including server sockets), but when connecting to localhost, you can only connect to the same app. You could use normal files in one of the shared "known folders" (Documents, Pictures etc), but that is a fairly crude hack that necessitates polling and is visible to the user. -- Pavel Minaev commenting on this issue

So failing normal approaches I was thinking of using web services or reading/writing to a database in order to get some form of communication happening, both of which seem like overkill when the processes are running on the same machine.

Is what I'm attempting here making sense? I can see a need for a metro app to be the frontend UI for an existing service which is running on the desktop. Or is it better to just use WPF for the frontend UI running on the desktop (i.e. a non-metro app).

Community
  • 1
  • 1
dodgy_coder
  • 11,717
  • 10
  • 47
  • 63
  • 2
    What about a local WCF service? – Gleno Sep 19 '11 at 01:04
  • 2
    @Gleno that would be covered of "thinking of using web services" in the question. That said, I do wonder if it'll even work - if the implementation of WCF client library that is provided in .NET Core is built on top of WinRT sockets, then presumably the same "no localhost" restriction would apply. This needs to be checked. – Pavel Minaev Sep 19 '11 at 01:16
  • 1
    It looks like WCF's NetNamedPipeBinding and NetTcpBinding (over localhost) wouldn't be available anyway due to the restrictions in metro. That would leave web services or MSMQ bindings? Am not sure if WCF itself is available in metro to be honest. – dodgy_coder Sep 19 '11 at 01:16
  • 1
    @dodgy_coder List of .NET stuff available in Metro is here - http://msdn.microsoft.com/en-us/library/windows/apps/br230232(v=VS.85).aspx - and seems to include `System.ServiceModel` and friends. The question is, even when using WCF over HTTP, would it let you connect to localhost, or not? – Pavel Minaev Sep 19 '11 at 02:03
  • 6
    Let me turn your question around and ask you: What happens if the desktop service with which you're communicating isn't present? Remember that your application can only be installed from the store and thus it can't rely on the presence of the desktop service. – ReinstateMonica Larry Osterman Sep 19 '11 at 02:17
  • @Larry I think the described architecture might make sense for a LOB Metro app that runs in a controlled environment (where the background service is deployed by domain administrators). Alternatively, one could have a graceful fallback where the service is used if it is available. So there are circumstances in which the question is still valid. – Pavel Minaev Sep 19 '11 at 02:58
  • @Larry excellent comment - the metro app in question would have a dependency on the desktop service being running as well. I was only planning on it being an in-house app, not for publishing on the app store per se - maybe its not possible to have a 'private app', or otherwise could stick to running it in a 'test/development' mode. – dodgy_coder Sep 19 '11 at 02:59
  • As far as I know, there's no mechanism for deploying apps on a machine that didn't come from the store. – ReinstateMonica Larry Osterman Sep 19 '11 at 14:08
  • 3
    It appears that enterprises can sideload custom apps and bypass the Windows Store. If so, it would make sense that you could assume some applications were running in the enterprise ennvironment. That said, I think the original poster should use a desktop WPF frontend for his purposes. – Ankur Goel Sep 19 '11 at 20:22
  • @Ankur yes that's right ... as stated by Microsoft [here](http://msdn.microsoft.com/en-us/library/windows/apps/hh464912) ... (Metro style apps are) "Distributed through the Windows Store. Apps must pass certification so that users download and try apps with confidence in their safety and privacy. Side-loading is available for enterprises and developers." – dodgy_coder Sep 21 '11 at 00:39
  • This forum post describes a way to do it: http://forum.xda-developers.com/showthread.php?t=1541924 . You create a simple .NET service using "ServiceHost" - I didn't know about that, looks nice - then connect via HTTP, and it does all the RPC transparently. This local connection doesn't seem to be blocked. Although the author seems to be thinking of writing malware, the technique looks useful in legitimate scenarios, too. – jdm Aug 21 '12 at 08:49
  • @LarryOsterman Do you think Microsoft will fix their app store to either A) install desktop/service components along with metro apps or B) allow non-enterprise sideloading? My guess is that C) we are all headed for jail, but I'm still hopeful that Microsoft will stop trying to wall us in like Apple in the consumer space. – Wayne Bloss Dec 23 '13 at 14:38
  • I wouldn't dream of speculating about what Microsoft might or might not do in a future release. I honestly don't know. – ReinstateMonica Larry Osterman Dec 24 '13 at 16:27

8 Answers8

54

I'm porting my existing project to Win8 right now. It consists of windows service and tray application which are talking to each other via NamedPipes WCF. As you may already know Metro doesn't support named pipes. I ended up using TcpBinding for full duplex connection.

This post describes what functionality is supported.

Sample of my WCF server that Metro client can consume is here.

Also keep in mind that you can't use synchronous WCF in Metro. You'll have to use Task-based wrapper which is only asynchronous.

And thank you for you question. I was good starting point for me :)

Community
  • 1
  • 1
expert
  • 26,897
  • 27
  • 105
  • 198
  • 7
    Thanks for this ... that's a great help. Its good to see a practical answer instead of just being told that it shouldn't / can't be done. – dodgy_coder Feb 22 '12 at 00:53
  • 1
    It may be a stupid question... but you may connect to localhost using your sample or not? The question you link to shows the internals of Visual Studio (I deduced it from the path, but if I'm wrong, please correct me). Does WCF (combined with localhost) work outside of WCF? – dzendras Aug 21 '12 at 08:02
  • @dzendras What do you mean by "outside" ? – expert Aug 21 '12 at 14:57
  • when the app is run without VS's assistance (deployed) – dzendras Aug 21 '12 at 16:36
  • 1
    @dzendras Sure, it will work. It will work with localhost as well. – expert Aug 21 '12 at 20:03
  • 3
    I doubt an app like this would pass Store certification, though. – Ani Aug 22 '12 at 21:19
  • 1
    @ananthonline What part of license agreement does it violate? – expert Aug 22 '12 at 22:31
  • 6
    If anything this is the rule I would think that might be quoted **"3.9 All app logic must originate from, and reside in, your app package You app must not attempt to change or extend the packaged content through any form of dynamic inclusion of code or data that changes how the application interacts with the Windows Runtime, or behaves with regard to Store policy. It is not permissible, for example, to download a remote script and subsequently execute that script in the local context of your app package."** – Ani Aug 23 '12 at 15:44
  • This answer should include a caveat that it will very likely cause an application to fail Windows Store certification. – ehdv Jun 25 '13 at 23:59
  • 1
    @ehdv It's been a while now but as far as I remember Dell didn't have problems with certification. – expert Jun 26 '13 at 15:59
  • 1
    @ananthonline As far as I understand none of the apps internal logic comes from an external source. This is just simple server-client software where both runs on the same computer. – Hjulle Nov 28 '13 at 08:15
38

There were a number of questions like this at the end of a //build/ session I attended. Aleš Holeček, the exec who did one of the big picture sessions, came up out of the audience to handle them. Even if you're not a C++ developer, download that session and watch the Q & A. http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C

Metro apps can't count on desktop apps or services being installed on the machine. And desktop apps can't count on Metro apps running since they can be suspended any time. You need to start thinking differently. Listen to Aleš on this one.

Kate Gregory
  • 18,565
  • 8
  • 53
  • 85
  • 6
    This exact question seems to be asked at 47:20 in the video. – Pavel Minaev Sep 19 '11 at 03:01
  • 3
    ... and one more at 55:00. The answer, generally, speaking, seems to be "nope you can't do that". – Pavel Minaev Sep 19 '11 at 03:08
  • Thanks for the markers, yeah the speaker is saying that due to the strict sandboxing, its not really possible, but may be achieved by using the shared files workaround. Probably the best way then is to just assume they may not be on the same machine and use web services or WCF/tcp binding. – dodgy_coder Sep 19 '11 at 03:21
  • 1
    @dodgy_coder I'm not sure WCF/TCP (or HTTP) would work on the same machine. If the sandbox doesn't let you connect to `localhost` directly via a TCP socket, why would it let you do the same via WCF? – Pavel Minaev Sep 19 '11 at 03:34
  • @Pavel I was thinking of communicating via web services over a valid/live domain, not localhost... so in effect the comms go out to the internet (or intranet) and back. – dodgy_coder Sep 19 '11 at 04:06
  • 2
    Interestingly, there is built in support for communicating between two metro apps via [share contracts](http://www.zdnet.com/blog/microsoft/microsofts-new-windows-8-contracts-the-debut-of-the-developer-clipboard/10750) but this seems to be similar in usage to the clipboard, and for transferring one-way from a source app to a target app, rather than for implementing say a two-way communication protocol. – dodgy_coder Sep 28 '11 at 03:07
  • 4
    Seems to me that side-loaded LOB Metro apps would have no problem depending on an installed desktop app or service. I have a hard time believing this very practical scenario won't be supported. With Silverlight, we saw a gradual increase in desktop/native interop capabilities...I'm pretty sure something along these scenarios (named pipes, or memory-mapped files, or something...) will be supported (with guidance docs) in the future. – David Cuccia Mar 18 '12 at 01:41
11

Take note that with Windows 8.1 Update, communication between Windows Store apps and desktop components written in C# for .NET 4.5+ is now officially supported for side-loaded applications in Enterprise scenarios:

Brokered Windows Runtime Components for side-loaded Windows Store apps

To quote:

Recognizing that critical business functions and rules are embodied in existing software assets and that enterprises have a wide variety of scenarios for which the new application style will be highly productive, the Windows 8.1 Update includes a new feature called Brokered Windows Runtime Components for side-loaded applications. We use the term IPC (inter-process communication) to describe the ability to run existing desktop software assets in one process (desktop component) while interacting with this code in a Windows Store app. This is a familiar model to enterprise developers as data base applications and applications utilizing NT Services in Windows share a similar multi-process architecture.

Although implementing this approach is a bit on the complicated side initially, it allows for deep integration across Windows Store and desktop components. Just keep in mind that for the time being, it won't pass public Windows Store certification.

ig2r
  • 2,366
  • 1
  • 16
  • 16
5

There is an article on InfoQ about how to build loosely coupled Metro apps with protocol handlers. This is something which has been supported by Windows for a long time and one could foresee an desktop application register itself as a protocol handler and maybe the metro application can communicate through this mechanism.

I have no idea if this is possible, but it might be interesting to check out.

tronda
  • 3,774
  • 4
  • 30
  • 55
  • The article says: "The way you can do this in Metro [jump over to another workflow in a different application - because your app is meant to be small and highly focussed] is by leveraging protocols. For our example above the protocol may look like “acme-stock-purchase://client=123&stock=XYZ”." - Just what does it mean technically, "leveraging protocols"? – Lumi Dec 05 '11 at 19:48
  • The problem with this approach is that it's only one way communication. – expert Jan 27 '12 at 04:42
3

If you think that you can make an additional manual cmd operation, you can try :

X:/> CheckNetIsolation.exe LoopbackExempt –a –n=<packageID>;

CheckNetIsolation.exe is included in winRT install, so there is nothing extra to be installed.

I tried it: it works, even after package updating.

As shown on: http://msdn.microsoft.com/en-us/library/windows/apps/Hh780593.aspx

Here it is explained how to find out the packageID for your app: http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/82bad7d4-d52b-4731-a396-13ab9004c1cc/how-to-get-the-appid-of-a-metro-style-app-

adosaiguas
  • 1,301
  • 9
  • 13
fgalliat
  • 76
  • 1
  • I wanted to be able to communicate with localhost for an internal application and I could only make it happen on the computers not running VS using this command. – adosaiguas May 15 '14 at 13:43
3

Christophe Nasarre has blogged about a rather hacky way to do it using local files. The result is communication between desktop app/windows store app (referred to as DA/WSA in the blog), without having to switch between the UI of the two apps. He also blogged about another less hacky technique involving protocol handlers.

Note that having a WSA which communicates with a DA is explicitly forbidden by the store App certification requirements

Windows Store apps must not communicate with local desktop applications or services via local mechanisms, including via files and registry keys.

... but it restricts "local mechanisms" only. So I guess one can build a web service for routing the communications.

twj
  • 651
  • 3
  • 11
2

It is possible to communicate on the same machine from Metro app to desktop app using local service. I've implemented some time ago simple "proof of concept", how to bypass the WinRT sandbox using local service. It still needs some kind of "social engineering" or direct guide for installing the service, but anyway, it is possible.
I'm not sure though about the certification rules about "local service" communication when adding such app to Windows Store.

Sample here

By design Metro application cannot access underlying PC directly, only using WinRT API and available capabilities. But when you create back-end service for accessing the PC and all data there, it's basically no longer running in sandbox.

The only "problem" is that user must manually install this back-end service, but that won't be a problem using some "social engineering": User downloads "PC browser" Metro app, user can browse all pictures, music and videos, using WinRT API, but the app also shows message at the bottom: "Download our PC browser powerpack and browse your entire PC, for FREE"

User is redirected to web page, from where user can download classic desktop installer containing "PC browser" back-end service for accessing files on users entire PC. Once this desktop service is installed, the Metro app can detect it and use it for browsing the entire PC. User is happy, but the WinRT sandbox is compromised.

Of course this won't work on Windows 8 ARM tablets. Using this workaround it could be even possible to build Metro app clients for classic desktop apps like antiviruses, torrent/P2P clients, etc.

Martin Suchan
  • 10,490
  • 3
  • 32
  • 63
  • 3
    Not sure why you need to mention about social engineering... since the original question is talking about a desktop app/service talking to a metro app, it is expected that the user will need to install the desktop app/service separately. So what method of communication did you use between the desktop service and the metro app? – dodgy_coder Oct 02 '12 at 02:29
0

Maybe I missed the point but when activating the Private networks capability I can connect to a local running (http) server using the local IP address (not localhost). This enables my scenario where a winrt app communicates with a wpf desktop app

Wendelin
  • 26
  • 1