I've upgraded a [.vdproj MSI generator project built into VS2008] System.Configuration.Install.Installer with a ServiceProcessInstaller
and a ServiceInstaller
from Visual Studio 2005 to 2008. There are no customisations of consequence to the installer class (i.e., not trying to start or stop services or register children)
RemovePreviousVersions
is set to true
, and I'm changing the Version
and ProductCode
. This triggers an error during the install:
"error 1001: the specified service already exists"
Googling yields stuff (but not on SO until now):- Google for "The specified service already exists"
The most useful one I've seen to date is http://forums.msdn.microsoft.com/en-US/winformssetup/thread/b2d1bd22-8499-454e-9cec-1e42c03e2557/
however this doesn't answer the fundamental question:-
Given that the user can pick either:
a) an install location that's the same
or b) an install location that's different
what are the minimal code changes would one sensibly make to ensure that the old service gets uninstalled and the new one gets installed? Or is there something other than a code change required to resolve this for the basic scenario of upgrading v1.0.1 to v1.0.2 of the same service with the same name (i.e., signing)
(AIUI the strong naming only comes into play if one has a significant uninstall step in the old installer that you dont have in the new one.)
I generated a new installer in VS 2008 and it fares no better.
For now, my workaround is to stop updating the Version
and ProductCode
, forcing the user to manually uninstall when they are told they already have a version installed.
Addendum thanks to divo's probing: While the simplest hack that could possibly work is to say "if install step is called & its an upgrade, call the uninstall step for the service first", I'd like a proper officially blessed answer! (e.g., how does the simple hack cope when the service is being renamed during an upgrade?)