question

VladimirGregor-4693 avatar image
0 Votes"
VladimirGregor-4693 asked FayWang-MSFT commented

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

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.






windows-uwp
· 6
5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

FayWang-MSFT avatar image FayWang-MSFT ·

Hi, does the following answer help? Have you solved your issue?

0 Votes 0 ·
jtorjo avatar image jtorjo ·

Welcome to the world of Windows Runtime. A lot of cases make (some) sense only to the authors of WinRT. Same happens when you try to create a media video effect -- they're just restrictions someone made up with disregard of the consequences. And now, we -- the developers -- are paying the price.

0 Votes 0 ·
FayWang-MSFT avatar image FayWang-MSFT ·

Hi, is there any update?

0 Votes 0 ·
FayWang-MSFT avatar image FayWang-MSFT ·

Hi, do you have other questions?

0 Votes 0 ·
FayWang-MSFT avatar image FayWang-MSFT ·

Hi, is there any update?

0 Votes 0 ·
Show more comments

1 Answer

FayWang-MSFT avatar image
0 Votes"
FayWang-MSFT answered

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" />
</uap:Extension>
</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.









5 |1600 characters needed characters left characters exceeded
Toggle Comment visibility. Current Visibility: Visible to all users

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.