Question about installer classes/custom actions during setup & deployment projects.

[RMZ]

By default a VS.NET 2005 generated setup and deployment MSI will
prompt the user to "remove or repair" if they attempt to run the MSI
after already installing the application.

I would like to change this behavior so that instead the user is
prompted to "remove or reinstall". Is this possible? Do I need to user
a custom action to perform this? My understanding is custom actions
execute at the end of the install process... If I were able to do this
with a custom action it seems I would be manually going to the
registry and removing the key so the installer could overwrite, that
process seems like a hack to me and I would like to do this the proper
way.

My client is persistent about the installer UI prompting for "remove
or reinstall".

 

[RMZ]

By default a VS.NET 2005 generated setup and deployment MSI will
prompt the user to "remove or repair" if they attempt to run the MSI
after already installing the application.

I would like to change this behavior so that instead the user is
prompted to "remove or reinstall". Is this possible? Do I need to user
a custom action to perform this? My understanding is custom actions
execute at the end of the install process... If I were able to do this
with a custom action it seems I would be manually going to the
registry and removing the key so the installer could overwrite, that
process seems like a hack to me and I would like to do this the proper
way.

My client is persistent about the installer UI prompting for "remove
or reinstall".

The answer to my question seems multi-part.

1. It seems that knowledge of the Windows Installer is illusive even
to MS people, no good documentation on the SDK and nominal support for
the VS.NET 2005 Setup & Depolyment tools

2. The VS.NET 2005 Setup & Deployment tools are intended to provide a
simple MSI builder solution with scalability through installer classes
that can be written in .NET languages. However, the Setup & Deployment
tool included with VS.NET has its limits and the desired functionality
is an example of such a limit. Ultimately, some aspects of this tool
are non-configurable and the the developer looking to go past these
limitations can either use unmanaged C++ to target the Windows
Installer API and create a custom (albeit much more code-intensive)
solution -or- purchase a more robust third-party tool (e.g.
InstallShield or WISE).