Less Painful Windows Service Development

When developing Windows services applications, one of the most painful aspects is testing.

Sure, you can test individual component libraries separately with unit tests, but what about deploying and testing the system in an actual runtime environment?  What if your components are dependent on live communications (for example, two components that communicate via TCTP/IP bindings in WCF)?  You could use mocks, but at some point, testing the interactions of the full system will be necessary.

Typically, this is a painful process of either using installers to install and uninstall the service or manually starting and stopping an installed service to replace component library assemblies.

The pain can be alleviated by using automated batch scripts on the post-build event.

ECHO Checking for existing deployment…
\\<server>\<deployment-target>” GOTO COPYFILES

ECHO Found deployment; copying output files…
ECHO Stopping Windows Service…
\\<server> STOP <service-name>


ECHO Starting Windows Service…
\\<server> START <service-name>
ECHO Started Windows Service.

ECHO Did not find deployment target…

ECHO Completed build…

In this example, I’m deploying to a remote server on the local network (but it would work just as well on a local deployment).  I came up with the script a while back after I got tired of stopping services, copying binaries over by hand manually, and starting services when testing some appliactions that I was building.  This technique still requires a one time initial install to deploy the Windows service, but on subsequent builds,

  1. It checks to see if the deployment target exists,
  2. If so, it stops the service and replaces the binaries (I’ve left that script out since it’s particular to any given deployment),
  3. It restarts the service.

I find this particularly useful for testing WF applications in custom Windows services based runtimes and for testing WCF applications in custom Windows services based runtimes as it allows me to install the service once and redeploy the component binaries with each build with ease.

You may also like...