I am using VS2008. i am trying to do an upgrade to my existing service application. My setup project version is 1.0 and the service versions are 1.0.0.2 (file) and 1.0.0.2 (assembly). I made a few changes to the service app so I increased the versions to 1.0.0.3 for both the file and assembly. I rebuilt the service project. I changed the setup version to 1.1 and changed the product code, "DetectnewerInstalledVersion" and "RemovePreviousVersions" are both True. I rebuilt the setup project but when I try to run the new .msi, i get most of the way through but then get "Error 1001: specified service already exists"

why is this happening if the version are different. When I dont change the version of the setup project, I can install the new version without problems. I have been reading posts regarding issues similar to this but not really solving my problem. Thanks for any help. I am stumped.

It's happening because the service is installed with a Service Installer class, and the Install method just runs again and doesn't check if the service is already installed, so you get that error. There is no good way to deal with this. It is also a consequence of the RemovePreviousVersions behavior on VS 2008 that installs everything on top of the already installed product,so installing the service while it's already installed.

If the user changes the install directory then the service does need re-installing because its location is incorrect. If it goes to the same location as the old one it doesn't need installing because all you want to do is update the exe. This complicates the situation. Just to add to the confusion, there is also an Uninstall of the service that will run when the older product gets uninstalled as part of the upgrade. IMO the most practical thing to do is to rename the service in your new product so that it doesn't clash with the older one that's out there. Then your install of your service is completely separate from the previous one.

If you search this forum for PREVIOUSVERSIONSINSTALLED you'll see some service install threads.

---

Phil Wilson

Setup A has custom actions that install a service called SDL with (example) sdl.exe. There are install and uninstall custom actions so that if you were to install this and uninstall it then SDL would be installed and uninstalled.

Setup B has custom actions that install a service called SDL2 with a exe called sdl2.exe. There are install and uninstall custom actions that install and uninstall this service.

When B upgrades A, it's the uninstall of A that uninstalls the service because B causes A to uninstall.

This is what I meant, so that everything was totally separate, but it looks like you didn't change the name of the service executable. That would explain what you're seeing.

I use Virtual PC or Hyper-V virtual machines for testing so I can always revert and get out of broken situations.

To uninstall a service you can use the WMI scripting interfaces, vbscript. You can adapt this to uninstall your service.

dim servicelist, service, fso, a, plist,process,sname

Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("services.txt", True)
Set servicelist= GetObject("winmgmts:").InstancesOf ("Win32_Service")
msg = ""
for each service in servicelist
   a.writeline ("Displayname = " & service.displayname & " Name = " & service.name & " Started = " & service.started & " State = " & service.state & " Tagid=" & service.TagID) 
   sname=lcase(service.name)
   If left(sname, 8) = "service1" And service.state ="Running" Then service.stopservice
   If left(sname, 8) = "service1" Then service.delete 
 next

---

Phil Wilson

It's happening because the service is installed with a Service Installer class, and the Install method just runs again and doesn't check if the service is already installed, so you get that error. There is no good way to deal with this. It is also a consequence of the RemovePreviousVersions behavior on VS 2008 that installs everything on top of the already installed product,so installing the service while it's already installed.

If the user changes the install directory then the service does need re-installing because its location is incorrect. If it goes to the same location as the old one it doesn't need installing because all you want to do is update the exe. This complicates the situation. Just to add to the confusion, there is also an Uninstall of the service that will run when the older product gets uninstalled as part of the upgrade. IMO the most practical thing to do is to rename the service in your new product so that it doesn't clash with the older one that's out there. Then your install of your service is completely separate from the previous one.

If you search this forum for PREVIOUSVERSIONSINSTALLED you'll see some service install threads.

---

Phil Wilson

Thanks for responding.

I think i understand the issue here now but what i dont get is why? I mean isnt it a normal need/want to just have an application upgraded without having to uninstall the previous one first. Also I have been looking at how to do versions and I believed I was doing it correctly...increase the application version as well as the setup project version. is this not the proper way of doing it? I reviewed another post that you had responded to here
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/be85add9-6786-4144-bd9e-8d245bddc82a
and its seems that they were doing the same versioning as I am but it worked for them. am i not supposed to increase the setup version?

>> IMO the most practical thing to do is to rename the service in your new product so that it doesn't clash with the older one that's out there. Then your install of your service is completely separate from the previous one.

but i dont want to rename the service because then there will be two services running to do the same thing. If anything wouldn't I just want to remove the previous version myself and then install the new one?


I will do the search you suggested and see what else I can find. thank you again

There won't be two services running because you're still going to be uninstalling the old product - that's what RemovePreviousVersions will do. So there'll be two completely separate services with different names of the service and the service executable. When you install your new service the name of the service exe and the name of the service will be new, and will install fine, and the upgrade will uninstall the old service.

Visual Studio 2005 setups had a RemovePreviousVersions (which is the MSI RemoveExistingProducts action) that ran early in the install. An upgrade basically therefore ran the uninstall of the old version first, uninstalling the files and removing the service, and then ran the new install. The order of custom actions on an upgrade was therefore the uninstall CA of the old product followed by the install of the new product, and install CA for the new serviceso the old service was uninstalled and then the new one was installed.

Visual Studio 2008 setups do the RemoveExistingProducts at the end of the upgrade, so the sequence of events is as follows:

1) The new installcopies files over the old ones (which is why versions need to be updated) when their destinations are the same as the old files. Note that the customer might change the installation folder.
2) The install custom actions run to install the service. This fails because the service is still there from the older setup. Note that the actual file location of the service will be different if it was installed to an application folder that the user changed.
3) The uninstall custom action of the old setup uninstalls the old service (which might in fact be the same name as the service you just installed).

Keep in mind that updating the service executable with a newfile version iscompletely separate from the fact that there are sets of custom actions running to install and uninstall the service.


It's a long story. At the risk of slight exaggeration, I'll say that no setup professional ever installs servicesusing installer classes. Only Visual Studio setup projects send you down that path. Every else typically uses the built in MSI support for installing services (ServiceInstall and ServiceControl tables in the MSI file) and these integrate with Windows Installer sharing so that you wouldn't see this issue.

This thread has some info about reverting to the Visual Studio 2005 behavior:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/519faa07-5b4e-4546-bfb3-6f233bf7286f

---

Phil Wilson

Well i am can tell you that by no means am I even close to a setup professional. i am actually just starting on this but unfortunately it is quite urgent to get correct. I have read many times on the forums that the VS setup project make installs too easy and they hide information in the beginning but get you confused by the end (my current situation exactly).

I did as you suggested and changed the service name for the service installer to from SDL to SDL2 and it installed perfectly. I did notice some TBDxxx.tmp files in the install directory. What are these? So everytime i would make changes to my code I would have to also change this in order to get it to install correctly? This may be a menial thing that i am just not getting but I am trying to understand how the setup knows to uninstall a service by its previous name then.

On a semi related note then. I am trying to version my projects correctly. I have version 1.5 (both file and assembly) of my application but i am using setup version 1.0. My bosses believe that the setup version should match (1.5) so that when users check add/remove programs, they will see the correct version #. I believe differently. I dont think they have to match. Any suggestions? Should I also increase the version of the setup project on a build that just references a new executable.

Thanks again - your previous post was very helpful

I'm not sure what the TBD files are that are left behind. They might be temp files that are removed by a reboot. If you change the name to anyoldfile.dll (just to investigate) and then right-click->Properties, it may have some version, manufacturer info. My guess is that it could be a left-behind Dll that's related to the custom actions.

There's no requirement that a setup project version matches an assembly version in your setup. Your setup might install hundreds of files with all kinds of versions, and there's no connection between any one of those files and the version of your setup. The only requirement for updates to work is that both file and setup versions increase when you ship a new version of the setup.

---

Phil Wilson

I looked at the properties with the files as is and it gives the file versions of the previous executable so it does seem like it could be left behind from the previous uninstall. When I rebooted, they were removed.

>> The only requirement for updates to work is that both file and setup versions increase when you ship a new version of the setup.

and that I change the service name.


UPDATE......
Actually I just went and checked (WHY I DIDNT CHECK BEFORE IS UNKNOWN TO ME) but in the services console, i have both services (SDL and SDL2) I thought that the new install was supposed to remove this old one. Why are they both shown? and they were both running and they were pointing to the same exe! I thought this wasnt supposed to happen. Now I cant uninstall the older version.

Setup A has custom actions that install a service called SDL with (example) sdl.exe. There are install and uninstall custom actions so that if you were to install this and uninstall it then SDL would be installed and uninstalled.

Setup B has custom actions that install a service called SDL2 with a exe called sdl2.exe. There are install and uninstall custom actions that install and uninstall this service.

When B upgrades A, it's the uninstall of A that uninstalls the service because B causes A to uninstall.

This is what I meant, so that everything was totally separate, but it looks like you didn't change the name of the service executable. That would explain what you're seeing.

I use Virtual PC or Hyper-V virtual machines for testing so I can always revert and get out of broken situations.

To uninstall a service you can use the WMI scripting interfaces, vbscript. You can adapt this to uninstall your service.

dim servicelist, service, fso, a, plist,process,sname

Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("services.txt", True)
Set servicelist= GetObject("winmgmts:").InstancesOf ("Win32_Service")
msg = ""
for each service in servicelist
   a.writeline ("Displayname = " & service.displayname & " Name = " & service.name & " Started = " & service.started & " State = " & service.state & " Tagid=" & service.TagID) 
   sname=lcase(service.name)
   If left(sname, 8) = "service1" And service.state ="Running" Then service.stopservice
   If left(sname, 8) = "service1" Then service.delete 
 next

---

Phil Wilson

I can see how I caused that problem. I should have changed the exe name too. The problem with that is I wanted a seamless install of the new executable but without the hassle of having the user keep track of new executable, service names. It seems that the only way I can do that right now is to have them do an uninstall of the previous product first and then install the new one (witht he same service/exe name) Is my understanding of that correct.

I am wondering how come there is no good documentation on how to set up applications to accomplish this, including how to modify the custom actions, etc.

I did use the vb script you suggested the service was removed! Thank you for that (it is very useful to know how to use vb scripting)