Much thanks to Wayne Allen, who posted a comment on my debugging post. I can’t believe I didn’t think of his first suggestion myself. The second suggestion is more of what I was saying in my response to Patrick’s comment.
I had a similar list with one addition, adding a Thread.Sleep(10000); in the OnStart method inside a #if DEBUG so I had time to attach the debugger. I think this is the only way to really debug startup code.
Recently I’ve found a better way to deal with services, first I create a console project that has nothing but a little startup and shoutdown code. Then I create a “library” project that has the real meat of the service. Once I have everything to my liking I create a windows service project and installer/deployment project _place_holder;in the same solution as the console and library projects. The console project remains the startup project for the solution, but the installer uses the primary output from the service project.
The benefits are that debugging during development is trivial, it forces you to seperate the real functionality from the “host”, the final transition to a service is trivial.
As I said before, pulling all of that code out of the service not only makes good sense from a modular code standpoint, but it makes testing so much easier–whether you’re doing TDD or not.