Software Deployment

sikkert

You are right, self heal occurs on triggering the entry points. The property what MSIMaker was talking abt is DISABLEADVTSHORTCUTS=1.
I agree to you that it's a bad idea of removing comp guids and key paths. It works but that's not the way to remove advertising.
The best way is to set the above property and convert all the advt' info into registry table. There are different ways of doing it. One way is to import registry information (source) to the registry table (destination), seeing the progid’s ,clsid’s entries under Extension, Verb, TypeLib, MIME, Class, ProgId and AppId tables.
You all got to understand one thing. It’s not only advt’ shortcut’s which tend to selfheal, even if you launch an exe directly and if it is accessing any of the advt’ information which is in the Extension, Verb, TypeLib, MIME, Class, ProgId and AppId tables, application tends to self heal application if there are any missing keypath.

MSIRam

Sorry for the late reply but I have been down the coast for the last week and no internet available.

DISABLEADVTSHORTCUTS=1 is one way but as stated is not really pretty and could cause you some problems. I prefer to remove the component GUIDS and then use a custom action to remove the files on Uninstall Only.

To set up a little senarion where disabling of self healing is needed (at least on my part).

I have several home grown apps that we are needing migrated to Win7 using AdminStudio / Installshield.

The applications are quite old, that are not installed by MSI's. No DLL registrations, no COM controls, etc. The "setup.exe" file, is essentially a compiled batch file that first checks for the presence of the application in a specific location, then copies a folder from the network to the local drive with the associated files, and creates a shortcut in the start menu and desktop. The shortcut EXE points to the setup file. If it finds the app, it launches the executable. If it does not find it, it reinstalls the app, then launches.

So the reason for self heal in this case would be that we want to keep the logic built into the app already where if the developers update a file on the network, the app will copy the newer files down. This way we do not need to repackage the app every time an update is made. Use it more as a "placeholder".

Any ideas will be greatly appreciated!

Self healing occurs when your shortcut is advertised shortcut. You can change your shortcut to Non-Advertised one in your packaging tool.
If you want to do it in ORCA, then you need to change the Target column of your shortcut table to the path of exe from the feature name. Feature name in Target column implies advertised shortcut.

If you can work out which components may generate a self repair then you can remove the component guids for them.

Other than that you can select to not repair via both the Property table and also within your packaging software.

I dunno how Wise works, but if you in InstallShileld removes (or maybe change) the KeyFile/KeyPath that is generating the self repair, it will not repair.

/Jonas

ORIGINAL: jonasm

I dunno how Wise works, but if you in InstallShileld removes (or maybe change) the KeyFile/KeyPath that is generating the self repair, it will not repair.

/Jonas


Jonas,

I think you mean remove tne GUID for the keypath in the component table. This will also work depending on how the structure is setup.

Hi Jim!

What i ment is that you in the "Files and folder"-view (or the Registry-view) can right-click on a key file och key path and select "Clear keyfile".

/Jonas

ORIGINAL: jonasm

Hi Jim!

What i ment is that you in the "Files and folder"-view (or the Registry-view) can right-click on a key file och key path and select "Clear keyfile".

/Jonas


Oh I see.....now thats a good feature for sure. I might ask EdT at Altiris to add it to his feature request list for WPS.

Hi MsiMaker,

Which Property are you speaking about in Property table which will disable the self healing ability??? Basically i need to set keypath to all components but i dont want the Package(MSI) not to Self Heal????


Thanks,
Dev

Ok now your confusing me.

You said this. "I dont want my application to self heal(Configuring)? so what are the possible solutions to address this issue???? "

The answer to this is to remove the GUID's for the components that you dont want to self repair.

Why exactly do you want this app to have no self repair? You will be disabling one of the most useful parts of the Windows Installer standard.

Hi MSIMaker,

I agree to your point that self repair is an important feature of windows Installer Technology, If we remove the GUID's, During uninstallation will the component get uninstalled???

Thanks,
Dev

ORIGINAL: DevGowda

Hi MSIMaker,

I agree to your point that self repair is an important feature of windows Installer Technology, If we remove the GUID's, During uninstallation will the component get uninstalled???

Thanks,
Dev


No the files will remain behind during uninstall. You will need a Custom Action to remove them. You can set the CA to remove them on "Uninstall Only"

Thanks MSIMaker for ur Feedback

ORIGINAL: MSIMaker


Other than that you can select to not repair via both the Property table and also within your packaging software.



Out of interest, which property?

Thanks

I would also like to know which property you meant, MSIMaker. I have never heard of such a property before, so your statement makes me curious as to what you mean.

As for the original post:
Removing the GUIDs of the components will work, but I would say that it is an ugly solution that should be avoided. Windows Installer looses track of the installed files, it can not remove the files on an uninstall, if the installation fails (and thus rolls back) after the components files have been copied, they will be left behind, and you loose the reference counting system (and the files/registry keys might get deleted by other installations) is the biggest problems in my opinion.

But I thought that self-repair is only triggered through the entry points of the application. Take a normal shortcut vs. an advertised shortcut for example. The normal shortcut is just a link to the .exe-file that starts the application. This is not an entry point. An advertised shortcut however, is not a link, but a descriptor that tells Windows Installer to check the keypaths of all the components that is part of the feature the shortcut points to. If Windows Installer finds any missing/older version keypath's, it performs a self-repair. And THEN it starts the .exe-file the shortcut is pointing to.
So if you don't have any entry points in your installation, I belive you don't get any self-repair functionality either.

An entry point can be:
- an advertised shortcut
- a line in any of the followin Windows Installer database tables:
Extension, Verb, TypeLib, MIME, Class, ProgId and AppId

Do you have any of this in your installation? If so, you could try and change all advertised shortcuts to normal shortcuts, and move any entries in the tables mentioned above to the Registry-table.

And does anyone know i self-repair can be triggered by any other means? With the test's that I've made my self, my thoughts above do seem correct, but there is of course MANY scenarios I haven't tested [8D]

I'm sure I have read somewhere else there is a property to do it, but I can't remember, which is very frustrating. I already PM'ed MSImaker, but no answer yet.

MSIram:

I was 99% sure about that, so it's nice to get it confirmed:)

In WPS just set the keypath for the component to a directory, this sets the keypath value for the component to Null. (Also have a remove directory entry for that component in the removefile table.) This breaks one of the ICEs if the file is a executable or dll, but not that serious.

Another useful feature is the flag "never overwrite if key path exists" for the component. (0x0080 in the attribute column) Good if you have a data file that you want to keep.

Removing the GUID for the component is another solution, but I wouldn't use it unless the other options are not workable. In combination with a removefile entry on uninstall it should work.

The non-advertised shortcuts will only work if you have non-advertised dlls. (ie no entries in the class, progid, typelib tables) Otherwise these will trigger self-repair.

The question is really why do you want to remove self-repair? From this you can work out which method will be best suited.

hi all,

I agree to the point the self healing is an important feature of MSI, But it does appear ugly when it starts configuring, i.e the dialog box which appears during self healing. So inorder to avoid this dialog box appearing we can include the activesetup registry entry and for the first time it will not popup the dialog box. But later on if we delete any file in MSI it will show the configuration Dialog box, So how do we go about hiding this Configuration dialog box?????


Thanks,
Dev

So, you are saying that you would rather have a program that is not working, than an "ugly" dialog box that is repairing the program?
Or are you talking about temporary files that should be deleted sometimes, without being repaired? If so, I would put all these files in a separate component, and remove the GUID of that component. Just make sure you populate the RemoveFiles table, to make sure all files are removed when the program is uninstalled.

Good question. How do you hide the self-repair dialogs? Can you?

Can any one explain what are the types of isolation?

Can you explain why you have resurrected a post over two years old and appended to it a question which bears no relation to the original subject?