My current project involves deploying an upgraded .exe file that runs as a Windows Service. In order to overwrite the existing .exe with the new version, I currently need to:
Should it be necessary to manually remove a service:
You will have to reboot before the list gets updated in services
If in .net ( I'm not sure if it works for all windows services)
Unless I'm changing the service's public interface, I often deploy upgraded versions of my services without even unistalling/reinstalling... ALl I do is stop the service, replace the files and restart the service again...
I am using the InstallUtil.exe packed with .NET Framework.
The usage to uninstall is: InstallUtil '\path\to\assembly\with\the\installer\classes' /u so for example: installutil MyService.HostService.exe /u
The /u
switch stands for uninstall, without it the util performs normal installation of the service. The utility stops the service if it is running and I never had problems with Windows keeping lock on the service files. You can read about other options of InstallUtil on MSDN.
P.S.:if you don't have installutil in your path variable use full path like this: C:\Windows\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe "C:\MyServiceFolder\MyService.HostService.exe" /u
or if you need 64bit version it can be found in 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\' .The version number in path varies depending on .NET version.
sc delete "service name"
will delete a service. I find that the sc utility is much easier to locate than digging around for installutil. Remember to stop the service if you have not already.
I had sort of the same problem as you. I have a system service that i want to uninstall and afterwards reinstall as part of an update. On certain systems this would not work without a reboot. The problem was that a call to DeleteService() would return ok, but the following call to CreateService() would tell me the service was still there, but marked for deletion (error code 1072). The registry would reflect that, since the subkey was still there (under HKLM\System\CurrentControlSet\Services), but "DeleteFlag" was set to 1. From that point on, only a reboot could fix the situation.
Some things that don't work:
But here is what worked:
I noticed in some articles here on stackoverflow that net.exe has start/stop features as well (I only knew of sc.exe utility). And strangely enough, a "net stop svcname" plus a "sc delete svcname" worked! So net.exe must do something I don't do.
But net.exe doesn't contain an import to ControlService(), so how does it stop the service? I found out that net.exe spawns net1.exe, but net1.exe doesn't import ControlService() as well. I used the great API Monitor utility ( http://www.rohitab.com/apimonitor ) to see what net1.exe is doing, but it never called anything that looked promising.
But then I saw that it imports NetServiceControl() from NETAPI32.DLL (that had at least "Service" in its name!). MSDN says that this function is obsolete. Nevertheless, I found the prototype in LMSvc.h and some parameter description here: http://cyberkinetica.homeunix.net/os2tk45/srvfpgr/369_L2_NetServiceControlorN.html . When you load NETAPI32.DLL and use NetServiceControl(NULL, service_name, 3, 0, 0)
(3 is for SERVICE_CTRL_UNINSTALL, which is used to stop) the service is stopped afterwards. And it can be deleted and reinstalled afterwards without DeleteFlag or reboot!
So it was never a problem of deleting, but of stopping the service properly. And NetServiceControl() does the trick. Sorry for the long post, but I thought it might help someone with similar problems. (Just for reference, I use Win7 SP1 x64.)
Both Jonathan and Charles are right... you've got to stop the service first, then uninstall/reinstall. Combining their two answers makes the perfect batch file or PowerShell script.
I will make mention of a caution learned the hard way -- Windows 2000 Server (possibly the client OS as well) will require a reboot before the reinstall no matter what. There must be a registry key that is not fully cleared until the box is rebooted. Windows Server 2003, Windows XP and later OS versions do not suffer that pain.