If you're going to configure the settings via your installer then in Step 3 the Administrator should go through the installer to update the settings.
Either you set your setting via the installer or you don't. Mixing and matching gets you into all these crazy scenarios like below. My preference is to not set configurable settings via the installer and leave intelligent defaults + the applications "Tools -> Options" type configuration to change the rest. That doesn't work well in all cases... but settings manipulation via MSI is just problematic. On Fri, Nov 5, 2010 at 2:46 PM, marzena <marz...@email.cz> wrote: > Thank you, Rob, for your suggestion. But I am afraid this does not solve > my problem completely. I have been already considering implementing this > pattern, but I suppose that would lead me into the same problem - only > the problem would appear bit later.. > > Consider this scenario: > 1) user1 installs the application. Connection strings are updated to > target the database in production environment. > 2) user2 launchs the app through shortcut. Let's say I have implemented > the remember-property pattern - connection strings would be in that case > updated (the XmlFile element would do its job again), but since > properties would have been refreshed from registry, connection strings > would remain correct. So far so good. > 3) DB server crashes and the DB is moved to backup server. Connection > string file must be manually edited by administrator. New server name is > saved into connectionStrings.config file and application starts working > again. > 4) user3 launchs the app (his first time), just as user2 did in step 2. > Since the file has been manually modified, registry values stored in > registry by WiX installer are no longer valid. Result is that the config > file becomes corrupted and application can not connect to the > database. > > Isn't this scenario correct? May be I am missing something.. > > > I think I need a solution that would prevent the MSI installer from > executing the XmlFile element whenever new employee is hired and needs > to use my application. As I have already mentioned I tried adding a > Condition within the Component that is nesting util:XmlFile request, but > it did not work. > > > Marek > > > Rob Mensching wrote on Fri Nov 05, 2010 at 10:05 PM +0100: > > > I think you'll want to implement this pattern: > > > http://robmensching.com/blog/posts/2010/5/2/The-WiX-toolsets-Remember-Property-pattern > > > > On Fri, Nov 5, 2010 at 9:54 AM, <marz...@email.cz> wrote: > > > > > Hi all, > > > > > > i created WiX installer project for deploying my .net winform app on a > > > customer machine. The app is very simple - it only scans some documents > and > > > saves the images to database on a server. The scanner is quite > expensive > > > device, there is only one in the company, but there are approx. four > users > > > that can occasionaly use it. This is the reason, why the app is > installed > > > just on a single workstation dedicated only for scanning - most of the > time > > > it is free and any of these users can come, scan the docs and go > continuing > > > his work. > > > > > > Because the app is to be installed on a single machine and is supposed > to > > > be used by more than one user, i am doing a per-machine installation: > > > ALLUSERS is hardcoded to 1. > > > > > > Because the database servers in production are not controlled by me and > i > > > do not really know, where the database will be stored, i can not pack > > > correct ConnectionStrings.config file to the MSI archive. Instead of > it, the > > > MSI package just contains a general template of that file, which is > then > > > modified according parameter values provided by the user during > install. For > > > updating the connection strings I use util:XmlFile element. The > > > connectionstrings.config file is stored in installation directory > together > > > with app binaries. > > > > > > Everything seemed to work fine, until I simulated more users using this > > > per-machine installation. Executed my wix setup project under > user1-account, > > > the XML config file had been correctly updated and then I launched the > > > application and tested the connection strings are ok. Everything was > fine. > > > > > > Then I switched to another user account. The shortcut was already > present > > > in the program menu - just as I have expected since the installation is > > > per-machine. So I clicked the shortcut and then (unexpectedly for me) a > > > progress bar window "Wait until the configuration of product XY is > > > finished." appeared. (Note that my machine locale is not english, the > > > message would probably be slightly different on an english locale > > > workstation). After few seconds the window disappeared and my > application > > > launched. Unfortunately it was not able to connect to the database, > since > > > the connectionStrings.config file has been rewritten. New connection > strings > > > have been saved using default property values, which are not valid. > > > > > > I have been investigating why the setup launchs again whenever new > > > user-account tries to use it. It is because of the shortcut element > (the > > > keypath is targetting HKCU). When I remove shortcut from WXS, MSI is > not > > > launched again after switching user context. Unfortunately I can not > simply > > > remove the shortcut from the installer :-). > > > > > > Now I have setup program, which is able to configure connection to a > > > database according to input parameters. But any later attempt to use > the app > > > from a second user-account just sends this configuration down the > toilette. > > > In production environment this would mean, that an administrator has to > come > > > and manually change the connection strings every time new user tries to > use > > > the app, which is of course unacceptable behavior. > > > > > > The simplified version of my WiX project is attached. > > > > > > I have tried to resolve the problem, but nothing helped me: > > > 1) I have separated the <File> and the <util:XMLFIle> to independent > > > components. > > > 2) I Have Tried adding a <Condition>NOT INstalled</Condition> under > these > > > components. > > > 3) I have tried writing a registry value to HKLM during installation. > Added > > > a RegistrSearch and Property for that registry value and then used that > > > value as a condition (in fact just a replacement of "NOT Installed" > from the > > > previous) > > > > > > Can anyone help with this? > > > > > > Thanks in advice > > > > > > Marek > > > > > > > ------------------------------------------------------------------------------ > > > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > > > David G. Thomson, author of the best-selling book "Blueprint to a > > > Billion" shares his insights and actions to help propel your > > > business during the next growth cycle. Listen Now! > > > http://p.sf.net/sfu/SAP-dev2dev > > > _______________________________________________ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > > > > ------------------------------------------------------------------------------ > The Next 800 Companies to Lead America's Growth: New Video Whitepaper > David G. Thomson, author of the best-selling book "Blueprint to a > Billion" shares his insights and actions to help propel your > business during the next growth cycle. Listen Now! > http://p.sf.net/sfu/SAP-dev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
