views:

5033

answers:

3

I have a VS2008 application that includes a service project (I'll call it ServiceProject). I have the installation project (InstallationProject) set to RemovePreviousVersions. Additionally, I have Custom Actions set for InstallationProject, to Install, Commit, Rollback, and Uninstall the Primary output from ServiceProject.

Sometimes when I build new versions of the installer, I can install without an error. Often, when I get to the point of setting up the service (entering a username and password into the installer) - it fails with the error, "The specified service already exists".

I don't know why it's inconsistent, though I've considered that maybe there is some kind of signature for the service and if the service is unmodified, it is able to remove it successfully, but with modifications, it doesn't recognize the service. However, I rarely make modifications to the service, so I doubt that's it.

How can I make my installer successfully update the service without this error? My work-around is to manually go into Control Panel, uninstall the former application, then run the installer.

+3  A: 

Make sure that the assembly version of the service and the GUID (In AssemblyInfo.vb/cs) are getting changed when you deploy each new installer package. If it detects the same version then updates fail.

StingyJack
that particular guid is inline in the code (not in the GUI with an automatic version updater) - does it matter how I update?
pc1oad1etter
I tried updating the two versions (AssemblyVersion, FileVersion, something like that) and it allowed me to install -- but asked for a reboot. Would that be expected - that anytime the service is updated, the user will be prompted to reboot to finish?
pc1oad1etter
I dont know about the reboots. Perhaps its saying that because its easier for users to do that than it is to instruct them on restarting windows services.
StingyJack
need for reboot suggests files were locked - i.e., the service didn't get stopped properly. Something is going wrong.
Ruben Bartelink
Also @StingyJack: you say "updates fail", its more that updates work as designed - they dont consider the file to be newer, and hence do not attempt to upgarde the version as it is the same. But I've got a long way to go to get edit rights!
Ruben Bartelink
Not -1ing as it is a consideration, but the other answer is better
Ruben Bartelink
+7  A: 

In addition to making sure the file versions are different as StingyJack mentioned you have another problem. From the VS documentation (sorry, not online)

If you have set both install and uninstall custom actions in an application's setup project, and you have enabled the RemovePreviousVersions property in Visual Studio 2005, the previous version of the product is uninstalled during an upgrade. However, this behavior changed in Visual Studio 2008 as follows:

In Visual Studio 2005, the custom actions were called as follows on an upgrade from v1.0.0 to v1.0.1:

v1.0.0 custom action Uninstall()

v1.0.1 custom action Install()

In Visual Studio 2008, the uninstall action is not called, as follows:

v1.0.1 custom action Install()

If you created custom actions relying on the old behavior, you need to modify your code for the new behavior. This behavior change affects only updates, not uninstalls.

So you are installing a service using a custom action - but when upgrading the Uninstall part is not being called as you expect and you are trying to Install over an existing, running version.

I think that when its asking for a reboot is because it can't update the services file whilst its running.

Two options :-

Add code to your Install/Commit custom action to Stop the service, wait for the installer to replace the services files and then restart the service. See PonalSuper3's answer in this thread

Put the VS2008 behaviour back to how it worked in VS2005 (the old versions Uninstall custom action is called before the new version Install) by using Orca to alter the InstallExecuteSequence.RemoveExistingProducts to be immediately after .InstallInitialize - usually you set the .RemoveExistingProducts to 1525 but check your individual MSI.

I've added a script than you can add to your build process to change the MSI's InstallExecuteSequence

Ryan
+1  A: 

Put "Not (Installed OR PREVIOUSVERSIONSINSTALLED)" in the Custom Actions->Install Condition property.

Tomer Pintel