WIX: persist session data between C# CustomActions and subsequently displayed WIX Dialog

I am new to WIX and have been tasked with creating an installer that does the following:

*Deploys a build of our application without overwriting the App.Config file for the application

*Loads the key/values in the App.Config file and prompts the user with the "defaults" (existing values) and allows them to modify them before finishing

*SAVES the values the user provided (or defaults if the user made no changes) back to the App.Config file for use with the application.

I've got the WIX dilalogs and custom actions laid out successfully where after InstallFinalize, my "LoadDefaultOptions" CustomAct开发者_Python百科ion is executed, which successfully takes the installation directory and the app config file name, loads it in an XML reader, and parses the key/value pairs, setting them into the session variable in this manner:

session[key.toUpper()] = value;

My custom action(s) are defined as:

<CustomAction Id="LoadDefaultOptions" Return="asyncWait" Execute="immediate" BinaryKey="aeserverDbDialogPackage.dll" DllEntry="LoadDefaultOptions"/>
<CustomAction Id="SetConfigOptions" Return="check" Execute="immediate" BinaryKey="aeserverDbDialogPackage.dll" DllEntry="SetConfigOptions"/>

The LoadDefaultOptions executes as such:

<Custom Action="LoadDefaultOptions" After="InstallFinalize" />

I have the custom dialog edit properties set like this:

<Control Id="CCPDbConnString" Type="Edit" X="20" Y="62" Width="150" Height="18" Property="CCPCONNECTIONSTRING" Indirect="no" />

There's a matching Property tag earlier in the WXS file like this:

<Property Id="CCPCONNECTIONSTRING" Secure="yes" ></Property>

...And the LoadDefaultOptions customAction overwrites the session var like this:

session["CCPCONNECTIONSTRING"] = <value parsed from file>;

According to session logs, this works as expected, the xml parse works, and the session vars are set.

My problem is when my custom dialog comes around to prompt the user with those stored defaults AFTER the LoadDefaultOptions CustomAction has run. The ORIGINAL property values of the session variables seem to have "stuck" instead of being overwritten by the custom action that loaded the defaults via the xml file and stored them in the session. (they are blank as their original properties are defined, or in the case I define them otherwise, they show those values instead of the session written values)

How do you get Dialogs to "read" overridden session variables by CustomActions?

Ultimately I want to load those values from the app config, prompt them back to the user in an optional dialog prompt off the exit screen (which works so far, aside from not getting updated session vars), and then on command from that prompt dialog, run another custom action to re-write the App.Config file with the settings provided from the custom dialog...

I just can't get the session vars to PERSIST!!!

Any ideas? am I completely off base attempting to use the session in this manner? how else could I parse the app.config file, and allow an installation user to change app settings if not by session?

Apparently, part of what I'm trying to do is more or less impossible... You cannot modify the session vars in the InstallExecuteSequence for use in dialogs... this can only be done in the InstallUISequence...

Therefore, I cannot READ AND PROMPT USERS FROM my App.Config on first installs as the file will never have been deployed during the period of time that it would be possible to do.... Seems the only time this would work is during an UPGRADE where the App.Config file exists from a prior install in the same location from which the original install occurred.

I'm going to go at it from this point of view, with NO (or hard-coded) default settings during a fresh installation, with an attempt to parse and use as defaults EXISTING app.config settings during upgrade installations... That should take care of my requirements!

If you schedule your custom action after InstallFinalize it won't run elevated during a managed installation / UAC type story. I also have a question, have you considered moving this configuration data to the application where it's easier to manage it as a first-run pattern?