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.