Jabo

I have a program that I'm looking into converting the meat of the program into a service, and for two reasons: to free up the user interface while it's processing and so that it will run even if the pc is not logged in.

The part of the program I'm wanting to make into a service also emails and prints depending on options set in the user interface. Would this be impossible/impractical with the way my program is set up and would it pretty much take a whole rewrite of my program?

MasterWill

I am in the process of designing a couple of services for the office to handle background data processing, so I am familiar with the dilemma. I wish that I could tell you that writing a service is straightforward, but having only used the express editions of VS I have found it to be a bit of a pain; not impossible, but not as simple as I would like. If I am not mistaken, the purchased VS editions have templates for Windows services, so that should get you to at least a starting point.

As for requiring a whole rewrite, I guess that would depend on how much your classes are tied into your GUI. If they are loosely coupled it should be relatively easy to pull them out and put them into a service EXE.

The problem that I am trying solve at the moment is to how to communicate with the service and where to put the configuration settings. I have a feeling that I will wind up using some sort of named pipes or TCP connection, but I have been looking into COM+/DCOM as the communication channel and have had nothing but headaches so far. I guess WCF could be an option as well, but I am not familiar at all with that.

I would suggest if you do separate the logic out into a service, look into using BackgroundWorker objects for handling the emailing and printing functions. They are easier to work with than threads (they actually encapsulate background threads) and only require overriding a couple of methods. Depending on how much these functions do, you may even want to separate them into their own services as well; overkill for simple stuff, but more robust for complex spooling solutions.

Glad to help if you want to bounce ideas around; would help me out as well.

__________________
-- William

Jabo

The emailing and printing is just an after-effect of the part I'm wanting to make into a service. The first part runs through completely, then, depending on results and settings, will email and/or print the results. At present, the results are displayed in a textbox and also saved to a text file. If there were any problems, an errstring is built with all bad results, and if the errstring is not blank at the end of the run, it's emailed/printed.

From what I've read about services so far, they can't communicate with the GUI, and the only control you have over the service is stopping, starting, pausing, loading and unloading. There has to be a way to get the settings to the service, though. Probably an ini file that is registered with the pc through the registry, I'm guessing. The service can't interact with the user space at all.

kruptof

How about the client server model. Where you have the services as the server and the UI as the client.

__________________

MasterWill

Love your quote line, BTW ...

That's basically what I was getting at was some sort of client-server design. The question is, what communication type to use: sockets, pipes, CORBA, COM, WCF, etc. Obviously there are a million and one ways to do any task, but getting the most efficient one is the trick.

As for the settings being in an INI file or registry key, that's a fast way to set it up and very easy to modify. I was thinking more along the lines of having a way to tell the service to re-read those settings without having to do a restart of the service ... basically a SIGHUP, to use a more unix-like way of describing it. Having to do a service restart is not unacceptable, but it would be nicer to be able to signal the service somehow that you made changes to its configuration, and to reload the settings at the next available interval. For example, your service is in the middle of processing a large quantity of data. You make some changes to the INI file or the registry and you want the service to reload its settings before starting on the next dataset. Do you want to have to stop the service (and wait for it to finish what it is doing) and then restart it? What happens if you stop the service and it has not completed the dataset it was processing? The new settings will be read when you restart it - are these the correct settings for the incomplete dataset? It would be smoother and, IMHO, more elegant to tell the service to schedule a reload of the settings and allow it to handle that reload as part of its natural processing scheme.

__________________
-- William