It might seem like a giant leap backward to bother with installing a Windows service in a worker role. After all, the Windows Azure and Visual Studio teams went to a lot of trouble to create worker roles as a core part of the platform. Worker role code is monitored by the fabric controller, so we know when it is no longer healthy and we can take steps to remediate. Windows services have additional plumbing associated with them so they can be started up, paused, shut down and managed by the Services.msc MMC plug-in. So why bother?
At this point I know of only one good reason: on-ramping to the cloud. You might have a Windows service that you rely on and want to do a proof of concept on Windows Azure but not want to take the time to refactor to worker role code. I’m sure that there are other good reasons and I’d love to hear them!
The process to making this happen is pretty simple. It involves the use of admin mode (available with the 1.3 SDK) and a short cmd script. Here’s a brief overview of the process:
When you’ve got it set up correctly, your service will install automatically each time an instance of your role starts up.
Here are a few details:
InstallService.cmd creates a new user account and makes it an administrator. This user account is needed for the InstallUtil invocation. The last line (exit /B 0) is to ensure that the script exits with a good return code. This allows you to RDP into the instance while testing. If you didn’t do this, the worker role will cycle, attempting to get a clean start. Once your code is clean, you can remove the exit.
One more thing: what did I put into my worker role code? Nothing! I just used the code as it comes out of the template. It loops, waits 10 seconds, loops, etc.