CODEWITHSUNDEEP
.netvb.netservice
Goro
Goro

Reputation: 10249

Optimal way for a service to interact with the user

My application needs to be a service (it needs run regardless of whether a user is logged on), but I also need some sort of client control/oversight over what it is doing. What is the optimal way to do this?

  1. Write a separate application to communicate with the service application - I see that as best solution in terms of stability, since the applications will be decoupled somewhat

  2. Use callbacks on system events in the service application to load UI forms directly from the service application - I see this as being easier to deploy.

Which way do you think I should go ?

Upvotes: 1

Views: 149

Answers (2)

Brian M.
Brian M.

Reputation: 826

The former is usually more ideal. Serivces are indeed meant to run without user interaction by design, and trying to do UI things with them can be a huge pain.

A windows forms application and a service could communicate in a number of ways: Named Pipes, sockets, dde, etc. I've used named pipes in the past to control/interact with services, and it's pretty easy to get going, especially if you just need the service to spit out some random data every once in a while. All the client would have to do is listen.

As for deployment, the windows forms app would likely not have many, if any, dependencies that the service itself does not have, so deployment is just including another .exe in your setup package.

Upvotes: 1

Mark Avenius
Mark Avenius

Reputation: 13947

I have used the first option in the past because you will run into issues when attempting to load UI forms from a service (as is option 2). You would need to launch another application in order to show forms to the user, so it makes more sense to have the application launch based on the user's session rather than from the service.

Upvotes: 2

Related Questions