UWP: Merging AppServiceProvider with its 'Windows Runtime Component' results in AppServiceConnectionStatus.AppUnavailable

Question

I've started experimenting with App Services. I followed the instructions here EXACTLY.
I ended up with a Visual Studio Solution, which contained 3 projects:

• ClientApp (Universal Windows)
• AppServiceProvider (Universal Windows)
• MyAppService (Windows Runtime Component)

Everything worked as expected. Then I did an experiment. I realized, that the "MyAppService" project only contains one class - the Inventory.cs. That's it. The "MyAppService" is obviously not an application, as it doesn't contain the application manifest. So I thought, why not to merge the two projects - AppServiceProvider and MyAppService into one project only. I took the only project file that it contained - the Inventory.cs (apart from the mandatory files, such as AssemblyInfo.cs, etc.) and copied it to AppServiceProvider project. I deleted then the "MyAppService". But since that, the "ClientApp" stopped working. Its "AppServiceConnection" object is no longer able to connect to "AppServiceProvider ", because its "OpenAsync" method returns AppServiceConnectionStatus.AppUnavailable.

I do not understand, why the logic of the actual application service has to be implemented in a separate project, whose type is 'Windows Runtime Component'. The ClientApp communicates with "AppServiceProvider " anyway and "AppServiceProvider " does not add anything to "MyAppService ". It only references it and then it simply declares in its Application Manifest, that it is an "App Service" and specifies the "Entry Point" and some other mandatory interface data, but that's it.

I was also thinking of another approach, removing the "AppServiceProvider" and keeping only the "MyAppService " Windows Runtime Component (as it contains the entire application logic anyway), but then there's no way to specify its app-service interface, because Windows Runtime Component does not contain any Application Manifest!

Can anyone share some light into this?

Thank you very much.

Answer 1

Hello,​

Welcome to our Microsoft Q&A platform!

I do not understand, why the logic of the actual application service has to be implemented in a separate project, whose type is 'Windows Runtime Component'.

This is actually an out-of-process application service. An app service can be implemented as a background task. This enables a foreground application to invoke an app service in another application. To create an app service as a background task, add a new Windows Runtime component project to the solution, so the background task that runs in a separate process than your app's process.

So I thought, why not to merge the two projects - AppServiceProvider and MyAppService into one project only.

This is feasible. In that case, it changes from out-of-process application services to in-process application services, two running foreground applications can have a direct line of communication via an app service connection. App Services can now run in the same process as the foreground application and removes the need to separate the service code into a separate project.

But first you need to modify the manifest, removing the EntryPoint attribute from the element because now OnBackgroundActivated() is the entry point that will be used when the app service is invoked.

.manifest:

<Extensions>
&ltuap:Extension Category="windows.appService">
&ltuap:AppService Name="InProcessAppService" />
&lt/uap:Extension>
&lt/Extensions>

Then moving the service logic from its separate background task project into methods that can be called from OnBackgroundActivated() in App.xaml.cs.

Finally, in your client app, changing your AppServiceName to InProcessAppService. For more detail about this, you can refer to this document.