Visual C++ WinRT FAQ – Inter-Process-Communication

This is slightly related to the previous FAQ on connecting to localhost. While Metro apps can use contracts to communicate at some level with other apps, that is not equivalent to the traditional concept of inter-process communication. A metro app cannot communicate with a desktop app or even with another metro application on the same machine.

With desktop apps, the metro app cannot take for granted that it’s running or available, and thus it makes sense to not allow that. But you may be wondering why IPC is blocked between two metro apps. Well, metro apps can be in a suspended state at any given time, and there’s no sure way to predict its state. So even if there are two apps running at the same time, neither app can be sure if the other app’s ready to accept data or a command. This is quite likely why they decided to design it so that metro apps cannot talk to each other.

So, what’s the workaround? Again, the only reliable way an app can talk to another app on the same machine is to use a a 3rd service that’s running on the network, or to use a cliched phrase, use the cloud.

Visual C++ WinRT FAQ – connecting to localhost

This is probably one of the most frequently asked questions on WinRT in the forums. The answer is – no, you cannot communicate with localhost. You can communicate with a service running on the local network, the intranet, or the internet. But you cannot connect to the loop back address. This is by design. It’s a security measure, and also a side-effect of how a Metro app cannot take any assumptions about the machine it’s running on. And expecting a localhost service to be running is such an assumption. So what’s the alternative? Use the cloud :-)

Note: you can connect to localhost for debugging, but your app will not be approved for publishing to the store.

Visual C++ WinRT FAQ – Non-RT types in public signature

Your public WinRT classes cannot use non-RT types in their public signature. This is something people run into very frequently when they start writing WinRT components. For example, see the code below.

class Native { };

public ref class MyRef sealed
        voidFoo1(Native n) { } // <--This is fine

        voidFoo2(Native n) { } // <--This won't compile

You’ll get a compiler error there:

error C3986: 'Foo2': signature of member contains native type 'Native'

Note that this is by design. (If you think about it, it’s perfectly logical, since WinRT components can be consumed by any WinRT caller including non-C++ ones)