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.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
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.
Answered 09/08/2008 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 09/08/2008 by: AngelD
Red Belt

Please log in to comment
0
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.
Answered 09/08/2008 by: bkelly
Red Belt

Please log in to comment
0
"always assumed it to be addressed by Windows Installer directly
Maybe it will be addressed in next version [;)]
Answered 09/08/2008 by: AngelD
Red Belt

Please log in to comment
0
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 [&:]
Answered 09/08/2008 by: pgiesbergen
Orange Belt

Please log in to comment
0
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.
Answered 09/08/2008 by: AngelD
Red Belt

Please log in to comment
0
...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!!
Answered 09/08/2008 by: kiptek
Second Degree Green Belt

Please log in to comment
0
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.
Answered 09/08/2008 by: AngelD
Red Belt

Please log in to comment
0
ORIGINAL: pgiesbergen
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.
A 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.
Answered 09/08/2008 by: VBScab
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity