Windows Service Gotcha (or Test Your Code, Regardless of How Small Your Changes Are)

I originally posted in the C# forum, and I didn't want it to get lost in the chaff that accumulates there, so I decided to move it here.
 
-----------
 
I was testing a Windows service I wrote using Visual Studio 2008 on a Windows 2000 machine. I had originally targeted .NET 3.5 when I created the project, and had to re-target the assemblies to 2.0 before installing it on the target machine. When I installed it, the event log would say that the service started successfully, but a few seconds later, I would get an error event - an invalid operation exception.
 
I removed EVERYTHING from the service except a keep-alive thread so it would keep running once installed, and it still threw the exception.
 
Thinking it might be a flaw in VS2008 when changing from .NET 3.5 to .NET 2.0, I tried creating an entirely new solution targeting .NET 2.0 from the start. It still threw the exception. After puzzling over it for a while, I had an epiphany.
 
The installer class sets the name of the service. One thing that all windows services do (when you create them with the VS2008 template) is calls the InitializeComponent() method. I had always deleted this call in prior services I had written since it seemed like a pointless thing to do, but this time, I had left the call in. In InitializeComponent, it tries to set the service name to "Service1". This is NOT the name I gave it in the installer object. After changing the name to the same thing I used in the Installer object, it worked just fine - no exceptions.
 
When I changed the name of the service.cs file, I guess it missed that string in the re-factoring process. I spent four hours on this problem. The other fix for this would have been to NOT call InitializeComponent at all.
 
I had initially tested this service on my own Vista box, and it worked fine. While I was waiting for access to the Win2K box, I figured I'd fix the Service name (because it was showing up as "Service1" in the event log). I re-factored and compiled, but did not re-test it before trying it on the Win2K box (I figured the re-factor would have done what it was supposed to do).
 
The lesson here?
 
ALWAYS RE-TEST, NO MATTER HOW MINOR THE CHANGE IS PERCEIVED TO BE.


This is proof that even the programmers with 30 years in the industry make the most rookie kind of mistakes every once in a while.