Service installer fails on "repair" install

I have a VS Setup project for a C# Windows Service. In the Control Panel's
"Add/Remove Programs" applet, my service appears with a change button, which
when clicked gives an option to repair the install. If I do that, I get an
error message saying "The specified service already exists" and the install
fails. It seems like the repair install ought to be more forgiving. If
someone is repairing an install, stuff could be in some random state of
chaos, but if the service is fine, the repair will fail.

Similarly, I've noticed that if the uninstall successfully removes the
service but fails in some later step, rerunning the uninstall also won't
work. This time the uninstall is unhappy because you're trying to remove a
service that doesn't exist and the process fails again.

Is there some way for these scenarios to work in a more robust way?

Phil
Mon Oct 08 10:34:44 PDT 2007

This is a consequence of the fact that Visual Studio setups run custom
action code to install services (instead of the built-in MSI support). So
what happens is that a repair attempts to run your custom action again
because a repair is effectively a re-install. The install custom action
needs a condition (case-sensitive) of Not Installed so it doesn't run again
on a repair.

--
Phil Wilson
[MVP Windows Installer]


"Eric Smith" <EricSmith@discussions.microsoft.com> wrote in message
news:9699E39D-C82A-4058-B709-D919E111B301@microsoft.com...
>I have a VS Setup project for a C# Windows Service. In the Control Panel's
> "Add/Remove Programs" applet, my service appears with a change button,
> which
> when clicked gives an option to repair the install. If I do that, I get an
> error message saying "The specified service already exists" and the
> install
> fails. It seems like the repair install ought to be more forgiving. If
> someone is repairing an install, stuff could be in some random state of
> chaos, but if the service is fine, the repair will fail.
>
> Similarly, I've noticed that if the uninstall successfully removes the
> service but fails in some later step, rerunning the uninstall also won't
> work. This time the uninstall is unhappy because you're trying to remove a
> service that doesn't exist and the process fails again.
>
> Is there some way for these scenarios to work in a more robust way?

EricSmith
Tue Oct 09 08:31:03 PDT 2007

Hi Phil,

Thanks for your reply. Adding the "Not Installed" condition to the custom
action does in fact prevent the "repair" from failing. I don't understand
conditions all that well, but it seems that adding this condition prevents
the custom action from being called at all. While an improvement for the
repair case, it's still not ideal. What if the service got removed somehow?
Running the repair won't fix it if the service installation step is skipped,
right?

"Phil Wilson" wrote:

> This is a consequence of the fact that Visual Studio setups run custom
> action code to install services (instead of the built-in MSI support). So
> what happens is that a repair attempts to run your custom action again
> because a repair is effectively a re-install. The install custom action
> needs a condition (case-sensitive) of Not Installed so it doesn't run again
> on a repair.
>
> --
> Phil Wilson
> [MVP Windows Installer]
>
>
> "Eric Smith" <EricSmith@discussions.microsoft.com> wrote in message
> news:9699E39D-C82A-4058-B709-D919E111B301@microsoft.com...
> >I have a VS Setup project for a C# Windows Service. In the Control Panel's
> > "Add/Remove Programs" applet, my service appears with a change button,
> > which
> > when clicked gives an option to repair the install. If I do that, I get an
> > error message saying "The specified service already exists" and the
> > install
> > fails. It seems like the repair install ought to be more forgiving. If
> > someone is repairing an install, stuff could be in some random state of
> > chaos, but if the service is fine, the repair will fail.
> >
> > Similarly, I've noticed that if the uninstall successfully removes the
> > service but fails in some later step, rerunning the uninstall also won't
> > work. This time the uninstall is unhappy because you're trying to remove a
> > service that doesn't exist and the process fails again.
> >
> > Is there some way for these scenarios to work in a more robust way?
>
>
>