Prevent an MSI install from having any "Uninstall"

[clhug42]

We want to have a small MSI that basically just lays down files. We do NOT want it to have an uninstall of any kind. I know we can use the ARPSYSTEMCOMPONENT parameter to hide the Add/Remove Programs entry, but we don't want it to even have a hidden entry. We just want it to lay down it's files and not do any of the behind the scenes stuff in registering it's install in the registry or anything.

Is there a setting somewhere we can set to tell MSI not to create an "uninstall" at all for a package when it's installing? (I've tried to dig through things, and done some searching for one, but I couldn't find it if it's there.)

We thought about just using a self-extracting zip file, but there reasons we want to do it in an MSI.

Thank you.

[Cne9999]

You can skip the actions that register the program, features and components. Not recommended because it leaves you with the possibility of having an MSI do a couple of odd things. Perpetual repair if it breaks in the right place, break and have to be manually cleaned up, and of course there is little or no auditing capabilities if you do this.

It sounds like you are saying you want to run an MSI as a non-msi. Hmmmmm.

There are better ways to do what you are looking to do. iExpress, VBScript, JSctript, SMS Installer, Bat2Exe, cmd or bat files, Heck even xCopy and Robocopy are better etc...

What is the reason for the MSI if you aren't using any of it's functionality other then to copy files?

The way I see it there are too many cons not enough pros.

This quesiton sounds strnagely familiar to me though... :confused:

[clhug42]

So no simple flag we can set somewhere to just tell it not to log any of it's actions, kind of like the Disable Logging statement in InstallScript?

The reason we want to do MSI is because we've got a whole automated process that's built on working with MSI's. If we can just make this thing an MSI, then we can just use that existing automated handling. If we do something else, we have to make coding changes to that automated process to handle whatever the "something else" is.

[KathyMorey]

Create a custom action to set ARPSYSTEMCOMPONENT to 1.
Condition the following standard actions so they don't run - they're in the Execute sequence: RegisterProduct, RegisterUser, PublishFeature, and PublishProduct.

The resulting MSI will always run as a new install. It won't appear in Add/Remove Programs (or Programs and Features) and you won't need (or be able) to uninstall it. It will still write registry entries for its individual components, but since there is no corresponding product entry, these will be "orphans". I've found that the standard actions that write the component entries also do other things that you need to have happen, so there isn't any way around that.

We've since stopped doing this in favor of using InstallScript projects when we need this behavior, but if you need to use MSI's, the only drawback I've found is having the orphaned component entries.

[clhug42]

Thanks for the info. Yeah, we really don't want the component registry entries either. This is something that will run once a month on each user's PC (it updates data that the program uses for calculations). That would eventually create a BUNCH of orhpaned component values.

I looked at just using a quick-patch to update these files, and may still do that. My issue is that there are 4 different variations on these files (the values in the data are different) and the user needs to be able to change from one to another.

I wasn't sure how having 4 different patches with different files, but the same software "version" would act when trying to install one of those "patches" over the other patch, and if everything would still uninstall okay. (If it worked this would have the advantage of uninstalling those files when the software is uninstalled.)

But it's not a big deal if those files get left behind on an uninstall either, so I thought it might be easier to just separate these files from the install entirely and just "copy them" out there (and each different variation could safely overwrite other variations).