The app object and out-of-process servers (Windows Runtime apps using DirectX with C++)
[ This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation ]
You activate out-of-process server types from your Windows Store app by implementing the IGetActivationFactory interface, which is accessed by the app object. Here we explain how out-of-process servers work with the Windows Runtime and the app object.
Creating out-of-process servers
You can define your own Windows Runtime classes that can be used from your Windows Store app. Normally, your WRT class objects are loaded and run in-process with your app. Under some circumstances, you may want your classes to run in a different process from your Windows Store app. Here are examples of the scenarios where an out-of-process class is useful:
- Your app has background work that is performed in a separate process. Thus, your app may need to communicate with that background work process, and require an out-of-process class to perform this communication. This is a common scenario when you have NCB background tasks in a separate process to communicate the network traffic back to your application.
- Your app may require specific process isolation between your classes and your app's process.
- Your app may want to share the same class instance between multiple processes. This scenario is very uncommon.
For the cases where you use an out-of-process class, you choose the use the CoreApplication.Run overload that takes IGetActivationFactory. The IGetActivationFactory interface has a single method which is used to retrieve an activation factory. Use this overload if you have a Windows Runtime DLL that is not loaded or activated as part of your app's process and you want your app to be able to access specific activatable types in it.
Now, an activation factory is a type that takes a specific Activatable Class ID (ACID) as a parameter, and returns a interface pointer to a class that is attributed with that ACID. The activatable classes must be registered in your app’s manifest. The same IGetActivationFactory interface is used in both out-of-process classes and in-process classes. In the out-of-process case, the Windows Runtime takes the class instance returned from the activation factory and passes it back to the process that activated the class.
Just like in-process classes, out-of-process classes are registered as part of the package manifest. Out-of-process classes use the windows.activatableClass.outOfProcessServer extension.
At run-time, the Windows Runtime will start your server process (if it is not already running) when an activation request comes in for a class that is registered as an out-of-process class. Once your process starts, you are responsible for providing you app object with an implementation of IGetActivationFactory when you call CoreApplication.Run. Your app must return an activation factory that can respond to activation requests for all activatable class names registered under the windows.activatableClass.outOfProcessServer extension in the package manifest. Your IGetActivationFactory implementation is called by the Windows Runtime to retrieve your activation factory. Once your activation factory is obtained, your activation factory implementation is called by the Windows Runtime to get an instance of the class that was activated, which returns this instance to the process that activated the class.
Note The overload for CoreApplication.Run that takes an IGetActivationFactory type is for activating out-of-process servers. For more information on working with out-of-process servers, see The app object and out-of-process servers.