Interaction of a GUI-based App and Windows Service

Question

I am working on personal project that will be designed to help manage my media library, specifically recordings created by Windows Media Center.

So I am going to have the following parts to this application:

• A Windows Service that monitors the recording folder. Once a new recording is completed that meets specific criteria, it will call several 3rd party CLI Applications to remove the commercials and re-encode the video into a more hard-drive friendly format.
• A controller GUI to be able to modify settings of the service, specifically add new shows to watch for, and to modify parameters for the CLI Applications
• A standalone (GUI-based) desktop application that can perform many of the same functions as the windows service, expect manually on specific files instead of automatically based on specific criteria.

(It should be mentioned that I have limited experience with an application of this complexity, and I have absolutely zero experience with Windows Services)

Since the 1st and 3rd bullet share similar functionality, my design plan is to pull the common functionality into a separate library shared by both parts of the application, but these 2 components do not need to interact otherwise.

The 2nd and 3rd bullets seem to share some common functionality, both will have a GUI, both will have to help define similar parameters (one to send to the service and the other to send directly to the CLI applications), so I can see some advantage to combining them into the same application.

On the other hand, the standalone application (bullet #3) really does not need to interact with the service at all, except for possibly sharing a few common default parameters that can easily be put into an XML in a common location, so it seems to make more sense to just keep everything separate.

The controller GUI (2nd bullet) is where I am stuck at the moment.

• Do I just roll this functionality (allow for user interaction with the service to update settings and criteria) into the standalone application? Or would it be a better design decision to keep them separate? Specifically, I'm worried about adding the complexity of communicating with the Windows Service to the standalone application when it doesn't need it.
• Is WCF the right approach to allow the controller GUI to interact with the Windows Service? Or is there a better alternative? At the moment, I don't envision a need for a significant amount of interaction, maybe just adding a new task once in a while and occasionally tweaking a parameter, but when something is changed, I do expect the windows service to immediately use the new settings.

Answer 1

The term used for interaction between programs on the same machine is "inter-process communication" - this should help you search for options. This answer suggests WCF is your best option (it will allow you to use named pipes for data transport, which is more efficient for your needs than HTTP).

Whether to split up your GUI apps is a matter of preference - it's all about usability - especially since you're the primary (only?) user. Weigh the benefits of each. For example:

• Separate: Easier to get to exactly what you want to do (think about your use cases and how often each will be used). Simpler UIs - no clutter from controls unrelated to your current usage.

• Together: One app to deploy. One app to find and launch. No accidentally opening the wrong one.

Shared code or GUI elements shouldn't be a consideration - they can be shared through a DLL just as easily as if they were being used in the same project.

One alternative is to combine everything, including the service, into single GUI app, which minimizes to the notifications area and launches on Windows startup. The "service" portion could run in a background thread, and you could have a context menu on the notification icon to open the settings dialog or to start a manual run. This replaces the need for inter-process communication with inter-thread communication, which is simpler to get working.

Answer 2

I would recommend you look at ASP.NET MVC instead of using WCF. ASP.NET services are generally easier to setup and get running, and it doesn't sound like you need the additional complexity that WCF can offer. If you're concerned about security, run the ASP.NET services over https and that should be good enough for your usage.

For the controller that you described, it's really up to you to decide on what it needs and how to structure it. If you're worried about adding unnecessary complexity to one of the two UIs, then don't do that. You can always add that functionality later on when it actually is required. Get it working first before you worry about adding every last bell and whistle into the application.

You'll get to a point while building the application to where it will either make sense to keep the two UIs separate or to join them together. You won't really know that answer until you get to writing the application though. You may find that one application with two tabs solves that particular issue for you.