Thanks for your response. Now I understand, what you've meant before.

I still do not understand, why the installer executes the component,
which deploys to the target file system a file, that has been already
deployed. On the other hand, you're right I am mixing two approaches.
Will try to change my setup so that a 'repair' can be executed when
connection string change is needed.

  

Rob Mensching píše v Ne 07. 11. 2010 v 00:33 +0100:
> 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



------------------------------------------------------------------------------
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

Reply via email to