DotNet Windows service is a long running executable, registered with windows operating system and do its work behind the scene. It gets activated when system boots, acquire its own windows session and start working without giving any clue to the user. Since windows start and manage these services, we have to register windows services in operating system.
I noticed it many times, the windows services which does simple operations, some of us having habit of writing code in the service onStart() event or write a private method in the same file/project and call it in the onStart() event. The problem with this approach is whenever we modify logic or functionality of existing windows service, we have to re-register executable with updated one. Doing this kind of geeky stuff on production server does not seem reliable. The best thing to avoid this situation is, write all code in a separate class library project. Generate a DLL out of it, refer it in windows service and call the DLL public methods. Now, we just have to register the windows service executable once and whenever there is an update, stop the service, replace the DLL and start the service.
I noticed it many times, the windows services which does simple operations, some of us having habit of writing code in the service onStart() event or write a private method in the same file/project and call it in the onStart() event. The problem with this approach is whenever we modify logic or functionality of existing windows service, we have to re-register executable with updated one. Doing this kind of geeky stuff on production server does not seem reliable. The best thing to avoid this situation is, write all code in a separate class library project. Generate a DLL out of it, refer it in windows service and call the DLL public methods. Now, we just have to register the windows service executable once and whenever there is an update, stop the service, replace the DLL and start the service.
Comments