[WiX-users] IisExtension: How to initialize IIS web app's Physical Path Credentials property in WiX (update)
Update:
I have noticed that strange behavior described below is machine/configuration
dependent:
The issue appears on this configuration:
Windows Server 2008 R2 Standard Version 6.1 (build 7600), IIS 7.5.7600.16385,
MSI v5.0.7600.16385
And on this machine exactly the same MSI works pretty fine (physical path
credentials is set OK):
Vista Enterprise SP2, IIS 7.0.6000.16386, MSI v4.5.6002.18005
Has anyone ever solved something similar?
I have created WiX installer package for the new project I am working on and
have a little unresolved issue related to proper registering the web
application
into IIS7.
The problem is that my web application is registered with incorrect Physical
Path credentials property value (this property can be accessed through IIS7 by
focusing the web app node and then opening its Advanced settings dialog box).
After installation of my application the value is set to a 'specific user'
with
username 'name'. Such user of course does not exist in my environment, which
causes the web app to fail on 500.19 when trying to open it in the browser.
So, after installing the app I have to open IIS and rest the Physical Path
Credentials property to 'application user (pass-through authentication)', in
order to force the web app to access its virtual directory using application
pool's identity. This manual change of that property solves the problem..
Does anyone know how to change WiX behavior, so that Physical Path Credentials
is set to 'application user' right out-from-the-box without any need to
manually
repair the value?
This is the fragment I use for configuring the IIS part of my solution:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Fragment
!-- Install to default web site --
iis:WebSite Id=DefaultWebSite Description='Default Web Site'
iis:WebAddress Id=AllUnassigned Port=80 /
/iis:WebSite
DirectoryRef Id=WebSiteContentDir
!-- Configuring app pool --
Component Id=ApplicationPoolComponent Guid={MY-GUID}
KeyPath=yes
util:User Id=ApplicationPoolUser CreateUser=no
Domain=MYDOMAIN Name=MYUSER
Password=MYPWD /
iis:WebAppPool Id=ApplicationPool Name=MyApp Identity=other
User=ApplicationPoolUser
ManagedPipelineMode=classic
ManagedRuntimeVersion=v4.0 /
/Component
!-- Configuring virtual dir --
Component Id=VirtualDirComponent Guid={MY-GUID} KeyPath=yes
iis:WebVirtualDir Id=VirtualDir Alias=MyApp
Directory=WebSiteContentDir WebSite=DefaultWebSite
iis:WebDirProperties Id=VirtualDirProperties
WindowsAuthentication=yes /
iis:WebApplication Id=WebApplication Name=MyApp
WebAppPool=ApplicationPool /
/iis:WebVirtualDir
/Component
/DirectoryRef
/Fragment
/Wix
Ww have already run into this issue on other projects and always solved using
a
powershell script fixing that property value that was executed automatically
during the installation. I believe there must be a way to make WiX install it
the requested way and hope to find an answer. Thanks in advance.
Marek
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] IisExtension: How to initialize IIS web app's Physical Path Credentials property in WiX
Thanks John, for the hint. Unfortunately it did not resolve my issue.
To make my question and related fragment (see below) more clear:
1) I have no issue with setting correct credentials to app pool itself, this
works absolutely fine. My problem is, that virtual directory created by the
installer is set not to use application pool's credentials to access its
content and use some other user account called 'name'. I do not know where from
this 'name' account arises from, it is never mentioned in my wix code..
2) of course, in real wix code I am using variables (wrapped inside square
brackets) for domain, user account and password information. I replaced these
in example code with constants, in order to keep the example as simple as
possible. So assume that there really is in my environment a user account
MYDOMAIN\MYUSER with password MYPWD.
Anyway I have noticed some additional User element attributes in your example,
which i have not been using (e.g. LogonAsService). I have tried to add these to
my code, but it did not make any change.
-Original Message-
From: John Cooper
Subject: Re: [WiX-users] IisExtension: How to initialize IIS web app's Physical
Path Credentials property in WiX
Date: 19.6. 2012, 16:13
Generally, your User element authoring should look something like this:
util:User Id=AppPoolUser CreateUser=no FailIfExists=no
LogonAsService=yes RemoveOnUninstall=no UpdateIfExists=yes
Name=[ACCOUNT_NAME] Password=[ACCOUNT_PASSWORD] /
The key difference is that your authoring is missing the property dereferences
(the square brackets).
Also, you can pass the fully-qualified ACCOUNT_NAME as a unit (ours is a UPN,
but I've had it work in NT format too).
--
John Merryweather Cooper
Build Install Engineer - ESA
Jack Henry Associates, Inc.(r)
Shawnee Mission, KS 66227
Office: 913-341-3434 x791011
jocoo...@jackhenry.com
www.jackhenry.com
-Original Message-
From: marz...@email.cz [mailto:marz...@email.cz]
Sent: Tuesday, June 19, 2012 8:57 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] IisExtension: How to initialize IIS web app's Physical
Path Credentials property in WiX
I have created WiX installer package for the new project I am working on and
have a little unresolved issue related to proper registering the web
application into IIS7.
The problem is that my web application is registered with incorrect Physical
Path credentials property value (this property can be accessed through IIS7 by
focusing the web app node and then opening its Advanced settings dialog box).
After installation of my application the value is set to a 'specific user' with
username 'name'. Such user of course does not exist in my environment, which
causes the web app to fail on 500.19 when trying to open it in the browser.
So, after installing the app I have to open IIS and rest the Physical Path
Credentials property to 'application user (pass-through authentication)', in
order to force the web app to access its virtual directory using application
pool's identity. This manual change of that property solves the problem..
Does anyone know how to change WiX behavior, so that Physical Path Credentials
is set to 'application user' right out-from-the-box without any need to
manually repair the value?
This is the fragment I use for configuring the IIS part of my solution:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Fragment
!-- Install to default web site --
iis:WebSite Id=DefaultWebSite Description='Default Web Site'
iis:WebAddress Id=AllUnassigned Port=80 /
/iis:WebSite
DirectoryRef Id=WebSiteContentDir
!-- Configuring app pool --
Component Id=ApplicationPoolComponent Guid={MY-GUID}
KeyPath=yes
util:User Id=ApplicationPoolUser CreateUser=no
Domain=MYDOMAIN Name=MYUSER
Password=MYPWD /
iis:WebAppPool Id=ApplicationPool Name=MyApp Identity=other
User=ApplicationPoolUser
ManagedPipelineMode=classic
ManagedRuntimeVersion=v4.0 /
/Component
!-- Configuring virtual dir --
Component Id=VirtualDirComponent Guid={MY-GUID} KeyPath=yes
iis:WebVirtualDir Id=VirtualDir Alias=MyApp
Directory=WebSiteContentDir WebSite=DefaultWebSite
iis:WebDirProperties Id=VirtualDirProperties
WindowsAuthentication=yes /
iis:WebApplication Id=WebApplication Name=MyApp
WebAppPool=ApplicationPool /
/iis:WebVirtualDir
/Component
/DirectoryRef
/Fragment
/Wix
Ww have already run into this issue on other projects and always solved using a
powershell script fixing that property value that was executed automatically
during the installation. I
[WiX-users] IisExtension: How to initialize IIS web app's Physical Path Credentials property in WiX
I have created WiX installer package for the new project I am working on and
have a little unresolved issue related to proper registering the web
application into IIS7.
The problem is that my web application is registered with incorrect Physical
Path credentials property value (this property can be accessed through IIS7 by
focusing the web app node and then opening its Advanced settings dialog box).
After installation of my application the value is set to a 'specific user' with
username 'name'. Such user of course does not exist in my environment, which
causes the web app to fail on 500.19 when trying to open it in the browser.
So, after installing the app I have to open IIS and rest the Physical Path
Credentials property to 'application user (pass-through authentication)', in
order to force the web app to access its virtual directory using application
pool's identity. This manual change of that property solves the problem..
Does anyone know how to change WiX behavior, so that Physical Path Credentials
is set to 'application user' right out-from-the-box without any need to
manually repair the value?
This is the fragment I use for configuring the IIS part of my solution:
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:iis=http://schemas.microsoft.com/wix/IIsExtension;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Fragment
!-- Install to default web site --
iis:WebSite Id=DefaultWebSite Description='Default Web Site'
iis:WebAddress Id=AllUnassigned Port=80 /
/iis:WebSite
DirectoryRef Id=WebSiteContentDir
!-- Configuring app pool --
Component Id=ApplicationPoolComponent Guid={MY-GUID}
KeyPath=yes
util:User Id=ApplicationPoolUser CreateUser=no
Domain=MYDOMAIN Name=MYUSER
Password=MYPWD /
iis:WebAppPool Id=ApplicationPool Name=MyApp Identity=other
User=ApplicationPoolUser
ManagedPipelineMode=classic
ManagedRuntimeVersion=v4.0 /
/Component
!-- Configuring virtual dir --
Component Id=VirtualDirComponent Guid={MY-GUID} KeyPath=yes
iis:WebVirtualDir Id=VirtualDir Alias=MyApp
Directory=WebSiteContentDir WebSite=DefaultWebSite
iis:WebDirProperties Id=VirtualDirProperties
WindowsAuthentication=yes /
iis:WebApplication Id=WebApplication Name=MyApp
WebAppPool=ApplicationPool /
/iis:WebVirtualDir
/Component
/DirectoryRef
/Fragment
/Wix
Ww have already run into this issue on other projects and always solved using a
powershell script fixing that property value that was executed automatically
during the installation. I believe there must be a way to make WiX install it
the requested way and hope to find an answer. Thanks in advance.
Marek
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] util:XmlFile executes repeatedly
Heureka! Component ... NeverOverwrite=yes / did the job. Původní zpráva Od: marzena marz...@email.cz Předmět: Re: [WiX-users] util:XmlFile executes repeatedly Datum: 07.11.2010 20:32:54 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
Re: [WiX-users] util:XmlFile executes repeatedly
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
[WiX-users] util:XmlFile executes repeatedly
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 ConditionNOT 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
[WiX-users] util:XmlFile executes repeatedly - source
Hi all,
attachments are probably not allowed :-).
This is the source related to my previous post. Thanks for any help on it.
Regards, Marek
?xml version=1.0 encoding=utf-8?
Wix xmlns=http://schemas.microsoft.com/wix/2006/wi;
xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
?define ProductID = ---- ?
?define ProductName = MyProduct ?
?define ProductLocalName = MyLocalLanguageProductName ?
!-- application's root registry path, where it stores its settings --
?define ApplicationRootRegistryKey =
Software\MyCompany\MyProject\MyBuildConfiguration ?
Product Id=$(var.ProductID)
UpgradeCode={----1112}
Name=$(var.ProductName) Version=1.10.1103
Manufacturer=MyCompany Language=1029 Codepage=1250
Package Id=* InstallerVersion=200 Compressed=yes
Description=$(var.ProductName) Installer Languages=1029
SummaryCodepage=1250 /
Media Id=1 Cabinet=media1.cab EmbedCab=yes /
!-- always install the app for all users --
Property Id=ALLUSERS Value=1/
!-- initialize properties used for adjusting connection strings. The user
will provide valid property values through command-line --
Property Id=DB_SERVER_NAME Value=please-specify-db-server-name/
Property Id=DB_NAME Value=please-specify-db-name/
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder Name=PFiles
Directory Id=CompanyProgramFilesFolder Name=CompanyName
Directory Id=INSTALLDIR Name=ProjectName
Directory Id=InstallDirApp Name=Bin /
/Directory
/Directory
/Directory
Directory Id=ProgramMenuFolder Name=Programs
Directory Id=AppProgramMenuDir Name=$(var.ProductLocalName)
Component Id=ProgramMenuDir Guid=*
RemoveFolder Id='AppProgramMenuDir' On='uninstall'/
RegistryValue Root='HKCU' Key='$(var.ApplicationRootRegistryKey)'
Type='string' Value='' KeyPath='yes' /
/Component
/Directory
/Directory
/Directory
DirectoryRef Id=InstallDirApp
Component Id=Executable Guid=*
File KeyPath=yes Source=$(var.MyProject.TargetPath)
Shortcut Id=ProgramMenuShortcut Name=$(var.ProductLocalName)
Directory=AppProgramMenuDir Advertise=yes
WorkingDirectory=InstallDirApp Icon=AppIcon.ico
IconIndex=0/
/File
/Component
!-- ConnectionStrings config file deployment and settings adjustment --
Component Id=ConnectionStrings.config Guid=*
File KeyPath=yes
Source=$(var.Csob.ChequesScanning.SmartShell.TargetDir)ConnectionStrings.config
/
!--/Component
Component Id=xml01 Guid=*--
!--Condition![CDATA[NOT Installed]]/Condition--
!-- this sets the connection strings according to provided parameters
--
util:XmlFile Id=SetConnectionString Action=bulkSetValue
File=[#ConnectionStrings.config]
ElementPath=//add Name=connectionString
Value=Data Source=[DB_SERVER_NAME];Initial
Catalog=[DB_NAME];Integrated Security=True;Pooling=True
Permanent=yes /
/Component
/DirectoryRef
Icon Id=AppIcon.ico
SourceFile=$(var.MyProject.ProjectDir)Resources\AppIcon.ico /
Feature Id=ProductFeature Title=MyProjectName Level=1
ComponentRef Id=Executable /
ComponentRef Id=ConnectionStrings.config/
ComponentRef Id=ProgramMenuDir /
/Feature
/Product
/Wix
--
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
Re: [WiX-users] util:XmlFile executes repeatedly
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-users] Unable to remove service on uninstall
Hi all, I'm new to wix - trying to solve trivial problem of creating MSI that installs new service on the computer and uninstalls it when the application is uninstalled itself.. Creation of the service, starting and stopping the service is OK. But when I uninstall the application the service is only stopped and it remains registered on my computer.. I'm using following code.. Component Id=MyServiceComponent Guid=12345678-4bbb-4dfc-9d27-2ec8bc588139 File Id=MyServiceExeFile Name=MyService.exe Source=$(var.TargetPath) / ServiceInstall Id=MyServiceInstall Name=MyServiceName Start=auto Type=ownProcess Vital=yes ErrorControl=normal / ServiceControl Id=MyServiceControl Name=MyServiceName Start=both Stop=uninstall Remove=uninstall Wait=yes/ /Component Thanks for any advice Marek Leitl - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
