some help trying to save user settings on upgrade!

[Kelter]

i need to make sure that certain registry values are retained after an upgrade (so the customer doesn't need to reconfigure after an upgrade).

Silly me, i figured this would be easily accomplished by (1)setting initial values in the property manager, (2)reading all the registry values of concern using the System Search view (such that any found values would overwrite the related properties), and then (3) set the reg values equal to the values of their associated properties.

what happens, unfortunately, is that all numeric values get written to the registry as string values with a "#" prepended, and all multi-string values get written as "String1[~]String2[~]String3[~]String4"

What's the MSI way of doing this? Can the correct behavior happen without scripting a whole mess of stuff?

[Kelter]

any idea where discrepencies in Client/Server Property Delta come from? some of them, i can understand, but why the prop difference? did you run the test in IS'08'?

[RobertDickau]

It seemed that the hard-coded properties you mentioned earlier at least survived to get written to the registry, in the wrong form but without being clobbered with "ACTION=INSTALL". If that's true, I wondered if setting the properties with custom actions would make any difference.

(I ran my test yesterday with InstallShield 2010, the only version I had at hand.)

[Kelter]

oh, and i just noticed that ACTION=INSTALL isn't really listed twice...it is the value of THE_PROPERTY_IN_QUESTION (as mentioned earlier in the conversation [THE_PROPERTY_IN_QUESTION]=" ACTION=INSTALL"

could this be the root of the problem? i mean...if the actual value of THE_PROPERTY_IN_QUESTION starts with a null,
[CODE]line 107 in the log:
MSI (c) (64:10) [17:05:00:135]: PROPERTY CHANGE: Adding THE_PROPERTY_IN_QUESTION property. Its value is ''.
[/CODE] (note that the value is reported as a null string...usually setting a property to a null string clears the property, rather than adding it...unless, as i suspect, the code that writes this line to the log during the property assignment does not convert the nulls to [~]s)

the client is trying to pass it to the server side, by means of a command line (a fatal flaw, particularly if it does not pass nulls as "[~]")

in the client side property dump at the end of the log, we can see on line 1219 that the client is holding the proper value, but possibly it's just not properly passed to the server.

if your test replicates my behavior when built on IS'08', then i think we've found a bug in '08'...but i find it hard to believe that something like this wouldn't have been caught earlier...

[RobertDickau]

I would think that it's Windows Installer handling the property hand-off from the client side to server side, so (as you say) I'd be a little surprised if it's a version-specific bug. The log file apparently doesn't contain the "real" command line passed from one side to the other (since property values generally need quotation marks if they contain spaces, and that's not the case here), so it's just speculation how ACTION=INSTALL is getting in there.

I don't have any inside information about how the values are passed around; depending on your schedule, it might be worth considering a different value-migration approach, such as InstallScript calling RegDBCopyValues. Naturally, as you pointed out before, you don't have rollback in that case, but if Windows Installer built-in behavior isn't doing the trick...

[Kelter]

just what i didn't want: well-informed bad news. 😛

i guess i could build up the scripted logic to read this value, then save it in a property (as a delimited list), then in the execute sequence, i'd just parse out the list and rebuild the multi-string value...or just cheat by using RegDBCopyValues() to copy the values to a backup location...that just adds another action to roll back, and it might requires modifying the user's system before the InstallInitialize action...

i would be really interested to either have you try your test on 2008, or to send you my project for you to try on 2010 and see if there's any difference...i only say that because you and i are trying the same thing and getting different results.

Either way, I owe you a drink! Let me know if you're going to be in the Boston area. I really appreciate all the time you've spent on this.

[RobertDickau]

You shouldn't have to modify the system before InstallInitialize; it's a bit tricky to pass properties to a deferred-mode action using CustomActionData, the first time you try it, but there's plenty of information around.

For what it's worth, here's the test MSI database created with IS 2010. (Usual disclaimer about its being tested once on one machine, no guarantees, be careful, etc.) You can see if it works on your system, and possibly import it as an IS 2008 project to see if anything behaves differently rebuilding with your version.

Good luck!

[Kelter]

perhaps i misunderstood what you meant with the RegDBCopyValues() solution... this would require backing the information up on thee user's system, and the sequencing restrictions on RemoveExistingProducts says that if i schedule it after InstallInitialize, then it has to come "before any actions that generate execution script." Deferred Execution actions generate script, so this prevents me from being able to do the backup someplace where i can also cleanup the backup on rollback.

i have no problems with passing properties via customactiondata. I've created some GetProp/SetProp functions that let me write code that doesn't care if it's in Deferred (read/write from/to a delimited list) or Immediate (read/write directly from/to the properties table) phase. :cool: If anyone wants it, just ask.

rockin! thanks for the sample! i'll post results when i get that far...