WCF Windows Service (Debugging)

Seeing the popularity of SOA rising, Microsoft's WCF services are rightfully being used more and more. Ofcourse, those services need to be hosted somewhere. One of the options for this is in a Windows Service (or technically speaking in a Process Service).

But, with the development of Windows Services comes the, generally accepted, burdon of deploying (compiling, installing, starting, attaching debugger, stopping, uninstalling) these services with every change we make, atleast if we do this by the book.

Not settling for that situation I counted my (too many) options and choose the following stratagy:

1) As goes without saying, allways make sure your service has hardly any "guts". Have all the logic in a seperate class that is seperately and indepentdently unittested.

2) Add a "program.cs" to your WindowsService-project, change its type to "Console Application" finally have Visual Studio start that project up when you start debugging your solution. (see source here: Run-windows-service-as-a-console-program.

Happy Servicing


Notes:

• Don't worry, by changing the type to "Console Application" you only tell Visual Studio to start (technically speaking "exec"-buildtask) the main-function of the program.cs you can still deploy your services without any changes to the sources/binaries.
  
  
• Try to group your Services in one Windows Services (technically speaking adding multiple appdomains to the process). If applicable this does save a significant amount of memory.
  
  
• Microsoft's upcoming OSLO concept might make this approach less needed;
  
  
• Add the following configuration block to your "app.config" to get usefull Console output:

<system.diagnostics>
  <trace autoflush="false" indentsize="4">
   <listeners>
    <add name="configConsoleListener"
type="System.Diagnostics.ConsoleTraceListener">
   </listeners>
  </trace>
</system.diagnostics>