views:

50

answers:

2

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" CustomAction 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?

A: 

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?

Christopher Painter
I've tried it after installFiles instead with the same disappointing results... (i.e. drop the files in their installdir, then run custom action to parse the app.config that got dumped)...The application is a scheduled task we're setting up in our environnments that isn't run by users directly, so "setting it up" on installation is the only logical option. It's part of a larger solution, but needs to be deployed as automatically as possible...More in general, how do you use session variables as modified by a custom action as the values for edit fields in dialogs in WIX?
Rimer
If you want to use them in a dialog then the custom action has to run in the UI Sequence prior to InstallWelcome. It also has to run as immeadiate execution to be able to set properties. Your app.config will be there to be read during upgrades but during the inital install it won't exist yet so you'll have to have default values. Also your user might want to pass in override values and/or use the install silently.I suggest reading: (it's using registry but same principals apply to xml)http://www.robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Property-pattern
Christopher Painter
Sounds like it may be impossible to do what I'm trying to do, then? Your link describes how to establish and then utilize input BETWEEN INSTALLER runs rather than within a single run... I do have my AppConfig file set to NeverOverwrite="yes" for this case you describe, but I would still like to be able to parse the values and prompt them back for change during a single install run...
Rimer
If you build your MSI uncompressed you might be able to use the OriginalDatabase property to resolve the location of your App.Config prior to it being installed. If you build a compressed database, you might be able to use DTF to stream the CAB out of storage, extract the App.Config to a temp directory and parse it there. I'm going to be honest though, these are pretty deep left field things to do so I'm not sure it's in your best interest in terms of fragility.
Christopher Painter
If it's an internal tool like you mention, it might work out well. Seriously though I'd consider moving this out of the install and into the application to manage if at all possible.
Christopher Painter
I guess another alternative is to skip the load portion, and maintain the initial config vars IN the WIX in addition to the AppConfig file... THANKS for all your insight!
Rimer
A: 

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!

Rimer