INI Files and MSI Removal
Anyone out there looked very close at this? It seems that the Windows Installer uninstall process will handle the removal of added or modified entries but does not restore the previous value as part of the operation (see the test cases below). Is this something that is simply considered acceptable, or do custom actions need to be written to handle what I would consider "expected" results?
Add New Entry
Test Case 1: Add a non existing Key-Value in a section that doesn’t exist in INI file; action is “msidbIniFileActionCreateLine†(Creates a .ini entry only if the entry does not already exist)
Expected Result: Section and Key should be created at the time of installation and remove at the time of un-installation.
Actual Result: As Expected.
Test Case 2: Add a non existing Key-Value in a section that already exist in INI file; action is “msidbIniFileActionCreateLine†(Creates a .ini entry only if the entry does not already exist)
Expected Result: Key should be created in the specified section at the time of installation and should get removed at the time of un-installation.
Actual Result: As Expected.
Modify existing entry
Case 3: Modify a value; action is "msidbIniFileActionAddLine" (Creates or updates a .ini entry)
Expected Result: Key should get modified at the time of installation and restored at the time of un-installation.
Actual Result: Key gets modified at the time of installation but gets removed at the time of un-installation. Un-installation doesn’t set the key value to its original value.
Case 4: Modify a value; action is "msidbIniFileActionAddTag" (Creates a new entry or appends a new comma-separated value to an existing entry)
Expected Result: - A new comma separated value should get appended at the time of installation and this comma separated value should get removed at the time of un-installation.
Actual Result: - As Expected.
Remove existing entry
Case 5: Remove complete key.
Expected Result: Complete key should get removed at the time of installation and restored at the time of un-installation.
Actual Result: Key gets removed at the time of installation but not gets restored at the time of un-installation.
Note: To remove a section user need to remove all its key values. Removing the last key value from a section deletes that section.
Add New Entry
Test Case 1: Add a non existing Key-Value in a section that doesn’t exist in INI file; action is “msidbIniFileActionCreateLine†(Creates a .ini entry only if the entry does not already exist)
Expected Result: Section and Key should be created at the time of installation and remove at the time of un-installation.
Actual Result: As Expected.
Test Case 2: Add a non existing Key-Value in a section that already exist in INI file; action is “msidbIniFileActionCreateLine†(Creates a .ini entry only if the entry does not already exist)
Expected Result: Key should be created in the specified section at the time of installation and should get removed at the time of un-installation.
Actual Result: As Expected.
Modify existing entry
Case 3: Modify a value; action is "msidbIniFileActionAddLine" (Creates or updates a .ini entry)
Expected Result: Key should get modified at the time of installation and restored at the time of un-installation.
Actual Result: Key gets modified at the time of installation but gets removed at the time of un-installation. Un-installation doesn’t set the key value to its original value.
Case 4: Modify a value; action is "msidbIniFileActionAddTag" (Creates a new entry or appends a new comma-separated value to an existing entry)
Expected Result: - A new comma separated value should get appended at the time of installation and this comma separated value should get removed at the time of un-installation.
Actual Result: - As Expected.
Remove existing entry
Case 5: Remove complete key.
Expected Result: Complete key should get removed at the time of installation and restored at the time of un-installation.
Actual Result: Key gets removed at the time of installation but not gets restored at the time of un-installation.
Note: To remove a section user need to remove all its key values. Removing the last key value from a section deletes that section.
0 Comments
[ + ] Show comments
Answers (9)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
Hi, Bob.
This is as expected. I don't know of any installation technology which natively restores original settings. Not that that's an excuse. It should be relatively easy to engineer that functionality into WI. And no, I don't consider it acceptable, never have.
For now, where restoration is required, before they're updated I write copies of INIs and export registry settings to .REG files via Custom Actions (CAs), with companion CAs to restore them on uninstall. Equally, files can be backed up to and restored from some location. On the latter score, I think the factor mitigating against it most strongly was the cost of storage. However, nowadays, with storage being cheap, it's something MS ought to be implementing. After all, they have the rather....esoteric System Restore Point doo-hicky.
This is as expected. I don't know of any installation technology which natively restores original settings. Not that that's an excuse. It should be relatively easy to engineer that functionality into WI. And no, I don't consider it acceptable, never have.
For now, where restoration is required, before they're updated I write copies of INIs and export registry settings to .REG files via Custom Actions (CAs), with companion CAs to restore them on uninstall. Equally, files can be backed up to and restored from some location. On the latter score, I think the factor mitigating against it most strongly was the cost of storage. However, nowadays, with storage being cheap, it's something MS ought to be implementing. After all, they have the rather....esoteric System Restore Point doo-hicky.
Posted by:
AngelD
15 years ago
Bob,
The only think I would add to Ian's reply is: I usually use AppSearch for searching for existing IniFile & Registry entries & write them down in the registry and read them back & restore them during uninstall if required. But it would always depend on the entry information of course, some may be changed during application usage for example user-stored INI-files so only machine data would be safer to restore.
The only think I would add to Ian's reply is: I usually use AppSearch for searching for existing IniFile & Registry entries & write them down in the registry and read them back & restore them during uninstall if required. But it would always depend on the entry information of course, some may be changed during application usage for example user-stored INI-files so only machine data would be safer to restore.
Posted by:
bkelly
15 years ago
Thank you both for the quick reply-- this is something I never looked that closely into and had always assumed it to be addressed by Windows Installer directly.
Posted by:
AngelD
15 years ago
"always assumed it to be addressed by Windows Installer directly
Maybe it will be addressed in next version [;)]
Maybe it will be addressed in next version [;)]
Posted by:
pgiesbergen
15 years ago
Restoring values can result in strange behaviour. You cannot know if the value to restore is the correct one.
Let's assume you have an existing ini entry with value X, package A changes the value to Y, and you saved the original value X somewhere with a custom action. Now comes package B and changes the value to Z, and saves the value Y somewhere. Package A is uninstalled, runs a custom action to restore the saved value X! Take it one step further and uninstall package B. The value will be restored to Y.
I can't remember having seen this scenario though [&:]
Let's assume you have an existing ini entry with value X, package A changes the value to Y, and you saved the original value X somewhere with a custom action. Now comes package B and changes the value to Z, and saves the value Y somewhere. Package A is uninstalled, runs a custom action to restore the saved value X! Take it one step further and uninstall package B. The value will be restored to Y.
I can't remember having seen this scenario though [&:]
Posted by:
AngelD
15 years ago
A good point Patrick,
that is why everyone should do conflict management to solve any potential conflicts if possible or be aware of them if any occurs.
that is why everyone should do conflict management to solve any potential conflicts if possible or be aware of them if any occurs.
Posted by:
kiptek
15 years ago
...everyone should do conflict management...
i almost fell off my chair laughing @ this one! took me back aways to when i was once told by a manager I was doing some work for:
We do not do conflict management because the reports show so many problems while everything is working in production!
I had to make a conscious effort to close my mouth, then an even bigger one to hold my tongue, go back to my desk, & cross my fingers for the next 30 days!!
Posted by:
AngelD
15 years ago
hehe nice.
Well, I may not understand the "the reports show so many problems while everything is working in production" but as it takes a bit more time during this mgmt many companies do not solve the conflicts but uses it as a reference while a conflict occur as it will pin-down the conflicting applications to save time during investigation during re-action.
Well, I may not understand the "the reports show so many problems while everything is working in production" but as it takes a bit more time during this mgmt many companies do not solve the conflicts but uses it as a reference while a conflict occur as it will pin-down the conflicting applications to save time during investigation during re-action.
Posted by:
anonymous_9363
15 years ago
ORIGINAL: pgiesbergenA reasonable point but surely only relevant to shared INIs like WIN.INI and who uses those any more? Generally speaking, each app has its own discreet INI so one wouldn't care what package B's going to do. As Kim says, conflict management would highlight any such scenario, in any event.
Restoring values can result in strange behaviour. You cannot know if the value to restore is the correct one.
Let's assume you have an existing ini entry with value X, package A changes the value to Y, and you saved the original value X somewhere with a custom action. Now comes package B and changes the value to Z, and saves the value Y somewhere. Package A is uninstalled, runs a custom action to restore the saved value X! Take it one step further and uninstall package B. The value will be restored to Y.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.