New embedded and enterprise-targeted features introduced with Windows 8.1 Update now make it so you can expose a Windows Runtime app to network services from desktop processes (apps or local services) outside of the app container. This means that a side-loaded Windows Store app can operate as an embedded or enterprise service client.
- Using network loopback in side-loaded Windows Store apps
- Brokered Windows RT components for side-loaded Windows Store apps
With Windows 8.1 Update, we now support the use of network loopback for side-loaded Windows Store apps. The Windows Store app connects to the service via a "localhost" address. Localhost is a special network machine name that resolves to the local machine. Once connected, the Windows Store app sends requests to and receives responses from the service as if that service were on a remote server. In this way, a Windows Store app can communicate with a local desktop server to perform actions that might otherwise be prevented by the Windows Store app sandbox or security model, or to use existing business-logic code without having to rewrite it. This solution is especially helpful when the Windows Runtime app can be installed on both a remote device and the same PC that runs the desktop server.
For a complete white paper on this subject, see Using network loopback in side-loaded Windows Store apps. You can also download accompanying sample code.
If you're looking to make use of existing business-logic code, and also to use the Windows Store app UI and UX tools, you can use a brokering mechanism to mix desktop and Windows Store app code together in one app.
The key is a new project type, introduced with Windows 8.1 Update, that supports marshaling Windows Runtime types between Windows Store apps and desktop components by using an interprocess contract.
For a complete white paper on this subject, see Brokered Windows Runtime Components for side-loaded Windows Store apps. You can also download accompanying sample code.