[WiX-users] What's the best way to deal with configuration data?
I have some questions about how best to deal with install or setup configuration data. I apologies in advance if this is a repeat of something that's already been covered in a previous post, but I haven't really found anything that speaks to this subject. At my place of work we have three approaches to deploying various parts of our system: 1. Install only: no configuration parameters in installer (i.e. no new public MSI properties) and no setup application that is run after install. 2. Setup wizard: an application that is launched after installer to guide a user through setting up a part of the application, e.g. setup a IIS website. The advantage with this approach is that the installer is simple; however, I do not believe this approach would scale or even work when deploying through Active Directory. 3. Configuration in installer: common settings are built into the installer, which then stores the values into the registry or configuration files. Here are some reasons why I don't like this approach: a. When doing a repair or modify, a property may not be set to the value of the original install; I know we could store the property value to the registry and reload it there after for repairs, modify, and upgrade but this feels like a rather messy approach. b. To work around some of the aforementioned issue, I'm seeing support engineers editing the MSI property table to set property values, then giving the installer to customers; hence, invaliding our digital signature. What I would like to know is if there are other approaches or if we're largely putting them all in practice? Is there a best practice? Also, is it a good idea in general to just turn off the modify and repair options? Cheers, Colin This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. We monitor our e-mail system and may record your e-mails. Thank you. -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What's the best way to deal with configuration data?
Hi guys, That sounds great and I've considered these approaches before. However, as I understand it (and I may well be wrong), when a repair or modify is invoked through the Programs and Features application (appwiz.cpl), it's not going to be able to see the original configuration file so all configuration properties are likely to use default values, which may be different to original setting. I suspect the registry is the most reliable storage location for these property values but again this doesn't seem like a good approach. Cheers, Colin -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Friday, 3 October 2014 9:23 a.m. To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? I have an XML file driven approach where in it reads the XML file, sets the appropriate properties, and continues the install without further UI. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Thursday, October 2, 2014 3:20 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? 2 is the approach I've been involved with, but the feature that makes it more corporate friendly is to allow it to be silent and read a file with all the parameters that would have been entered using the UI wizard. The general approach is that each relevant data item on a form has a public property associated with it (managed code here). Reflection can be used to set those properties. If each UI dialog was a form, then you can have a text file of data where each line is something like UserForm.UserName=Fred. That means set the UserName property on UserForm to Fred, and there'a public Execute method that's the equivalent of the Next button. The program itself knows that's invoked silently, so never invokes UI, it just does whatever it's told to do, setting properties etc. The UI is absolutely separated from doing the work so it can all be run from input data. It's the same general idea as silent MSI install with data passed as parameters. An extension would be to create a silent configuration file from a UI run as a model for all subsequent configurations or repairs of configuration. --- Phil Wilson On Wed, Oct 1, 2014 at 3:43 PM, Colin Sim colin@ipfx.com wrote: I have some questions about how best to deal with install or setup configuration data. I apologies in advance if this is a repeat of something that's already been covered in a previous post, but I haven't really found anything that speaks to this subject. At my place of work we have three approaches to deploying various parts of our system: 1. Install only: no configuration parameters in installer (i.e. no new public MSI properties) and no setup application that is run after install. 2. Setup wizard: an application that is launched after installer to guide a user through setting up a part of the application, e.g. setup a IIS website. The advantage with this approach is that the installer is simple; however, I do not believe this approach would scale or even work when deploying through Active Directory. 3. Configuration in installer: common settings are built into the installer, which then stores the values into the registry or configuration files. Here are some reasons why I don't like this approach: a. When doing a repair or modify, a property may not be set to the value of the original install; I know we could store the property value to the registry and reload it there after for repairs, modify, and upgrade but this feels like a rather messy approach. b. To work around some of the aforementioned issue, I'm seeing support engineers editing the MSI property table to set property values, then giving the installer to customers; hence, invaliding our digital signature. What I would like to know is if there are other approaches or if we're largely putting them all in practice? Is there a best practice? Also, is it a good idea in general to just turn off the modify and repair options? Cheers, Colin This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those
Re: [WiX-users] What's the best way to deal with configuration data?
And in the case of AD deployment, you'll just roll out a configuration file along with the MSI install? -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Friday, 3 October 2014 11:00 a.m. To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? I would only gather the minimum required information needed to install the application. Utilize a configure on first run model for application configuration, and write to an application/user defined storage location so that the user data is automatically persisted on repair/modify. Newer versions of Office do this from what I remember. -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, October 02, 2014 3:46 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? That is correct. Information that needs to persist to a repair or upgrade is persisted in the registry. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Colin Sim [mailto:colin@ipfx.com] Sent: Thursday, October 2, 2014 3:44 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? Hi guys, That sounds great and I've considered these approaches before. However, as I understand it (and I may well be wrong), when a repair or modify is invoked through the Programs and Features application (appwiz.cpl), it's not going to be able to see the original configuration file so all configuration properties are likely to use default values, which may be different to original setting. I suspect the registry is the most reliable storage location for these property values but again this doesn't seem like a good approach. Cheers, Colin -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Friday, 3 October 2014 9:23 a.m. To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? I have an XML file driven approach where in it reads the XML file, sets the appropriate properties, and continues the install without further UI. -- John Merryweather Cooper Senior Software Engineer | Enterprise Service Applications | Continuing Development Jack Henry Associates, Inc.® | Lenexa, KS 66214 | Ext: 431050 |jocoo...@jackhenry.com -Original Message- From: Phil Wilson [mailto:phildgwil...@gmail.com] Sent: Thursday, October 2, 2014 3:20 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] What's the best way to deal with configuration data? 2 is the approach I've been involved with, but the feature that makes it more corporate friendly is to allow it to be silent and read a file with all the parameters that would have been entered using the UI wizard. The general approach is that each relevant data item on a form has a public property associated with it (managed code here). Reflection can be used to set those properties. If each UI dialog was a form, then you can have a text file of data where each line is something like UserForm.UserName=Fred. That means set the UserName property on UserForm to Fred, and there'a public Execute method that's the equivalent of the Next button. The program itself knows that's invoked silently, so never invokes UI, it just does whatever it's told to do, setting properties etc. The UI is absolutely separated from doing the work so it can all be run from input data. It's the same general idea as silent MSI install with data passed as parameters. An extension would be to create a silent configuration file from a UI run as a model for all subsequent configurations or repairs of configuration. --- Phil Wilson On Wed, Oct 1, 2014 at 3:43 PM, Colin Sim colin@ipfx.com wrote: I have some questions about how best to deal with install or setup configuration data. I apologies in advance if this is a repeat of something that's already been covered in a previous post, but I haven't really found anything that speaks to this subject. At my place of work we have three approaches to deploying various parts of our system: 1. Install only: no configuration parameters in installer (i.e. no new public MSI properties) and no setup application that is run after install. 2. Setup wizard: an application that is launched after installer to guide a user through setting up a part of the application, e.g. setup a IIS website. The advantage with this approach is that the installer is simple; however, I do not believe this approach would scale or even work when deploying through Active Directory. 3. Configuration in installer: common
[WiX-users] Burn Prerequisite Install and Configuration
Our product has a requirement on SQL Server that must be tuned to our application's requirements. I would like to create a bootstrapper to do the following: 1. Bundle the most recent version of SQL Server Express into our bootstrapper and install it, if SQL Server is not present. 2. If a previous version of SQL is installed, have an option to upgrade it. 3. If the customer prefers to install a full blown version of SQL Server, provide an option for them to specify an URI (local path or network share) to their SQL Server package and product key. Then the bootstrapper can install and configure. 4. Install our product. Can anyone indicate if this is possible; if so, how do I go about it? This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. We monitor our e-mail system and may record your e-mails. Thank you. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] .NET Prerequisite, Burn, and the ARP
When a .NET package is successfully installed as a prerequisite for our Burn bootstrapper application, and the user cancels the install, the bootstrapper package is still listed in the Add/Remove programs. I understand that the .NET package is part of the bundle but from a user's perspective none of the product has technically been installed. Especially, when someone takes a look in the Add/Remove programs window, the bundle is there, and they assume everything is in place. Are there any settings to prevent this from happening? Alternatively, what are the strategies to deal with this scenario? This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. We monitor our e-mail system and may record your e-mails. Thank you. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Prerequisite, Burn, and the ARP
Phil: there's absolutely no need to apologise. All forum users (I know I am) appreciate your input and time spent helping out on the forum. I'll need to look into this issue anyway as part of a project of mine (which I'll get back to soon I hope). I'll report back anything meaningful that I find. I'll certainly give your suggestion, regarding the use of a dummy package ago. If it works though, it still feels like a hack as opposed to a proper solution to me. I haven't looked through the Burn engine code, but from my experience of using Burn to date (granted not very long) - it feels like at some earlier point in development, it was easier to piggy back of the bundle chain to support the runtime environment for the bootstrapper as opposed to having a clean and separate concept for prerequisite(s) specifically for the bootstrapper itself. Could any of the developers comment or share their insight into the design intent that has resulting in what we're seeing now? -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Thursday, 21 May 2015 1:11 a.m. To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] .NET Prerequisite, Burn, and the ARP I came across a different, but I suspect it might be a related issue, discussed in this thread http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/RollbackBoundry-Can-t-Upgrade-or-uninstall-bundle-td759.html . Frankly because of other responsibilities, I set this issue aside and did not fully dig into the cause or solution. In my case it was not the mba prereq, but additional prereqs at the top of my chain (vc runtimes, and .Net 3.51) which I install but never uninstall. When I had a RollbackBoundary immediately after a ExePackage with ExePackage/@Permanent=yes, and if while processing a package after the RollbackBoundary, in certain situations like user cancel, the rollback happened to the boundary, but the bundle was left in the ARP. When this happens I could not find any way to get an Uninstall (or an Upgrade) of that bundle to work. The log simply reports success which is correct since there is nothing in the chain that is not permanent, to uninstall, but the ARP registration remains. I eventually concluded that I should not use a RollbackBondary after a 'Permanent' package, and I also add a small simple MSI package immediately after the permanent package, so that there is a high likelihood that it installs. If a latter package fails, there remains something in the chain for the Bundle to uninstall, and then it removes the ARP registration. It has been my intent to get back to this and setup a test scenario that I can debug into and try to understand if my observations are accurate, and then file a bug or figure out a fix, but I have not gotten back to this issue. Sorry. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Prerequisite-Burn-and-the-ARP-tp7600376p7600382.html Sent from the wix-users mailing list archive at Nabble.com. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. We monitor our e-mail system and may record your e-mails. Thank you. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [wix-users] (deprecated) Windows Installer Repair Failure
We're doing a major upgrade and RemoveExistingProducts may not be schedule in the most efficient place, i.e. between InstallValidate and InstallInitialize. I'll attach the upgrade log in a following email as it's 42MB in size and I'm not sure if it'll be allowed. -Original Message- From: Nir Bar [mailto:nir@panel-sw.com] Sent: Wednesday, 29 July 2015 6:59 a.m. To: wix-users@lists.sourceforge.net Subject: Re: [wix-users] (deprecated) Windows Installer Repair Failure I must say that the description doesn't seem right Can you post the full log with no inline comments? If this is a major upgrade then depending on the scheduling of RemoveExistingProducts https://msdn.microsoft.com/en-us/library/aa371197(v=vs.85).aspx you'll get a full uninstall then full install, or delete/overwrite/add files. For minor upgardes you will not get any removal, just overwrite/add files. The partial log you posted isn't enough for me to understand which- if any- upgrade is occuring. - Nir Bar Freelance Developer Mail: nir@panel-sw.com Web: www.panel-sw.com - C++ On Windows, Linux and Embedded Platforms - WiX InstallShield -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/wix-users-deprecated-Windows-Installer-Repair-Failure-tp7600931p7600936.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This e-mail contains IPFX information which may be privileged or confidential and is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this e-mail in error, please advise immediately to the e-mail address above and permanently delete this message and any attachments. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. We monitor our e-mail system and may record your e-mails. Thank you. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[wix-users] (deprecated) Windows Installer Repair Failure
We use a PowerShell script to upgrade our development servers and our product
is contained in a 1.7GB MSI file. The PowerShell script copies the package from
a network share to the local %TEMP% directory, then executes the MSI in silent
mode. Upon successful installation the copy of the MSI in the %TEMP% directory
is removed.
On development servers, it is typical for developers to replace components that
are installed through the MSI with components they build themselves - these
components generally will have a higher version number than that installed by
the MSI. As a result, here is the scenario on upgrade and subsequently the
error:
1. When upgrading some components are marked as leave alone because they have
a higher version number than the new package.
2. The upgrade process performs an uninstall, which removes all components of
existing package (including those that were marked as leave alone - this must
be a bug in the Windows Install!!!).
3. The upgrade process performs an install; however, does not install the
components that were previously marked as leave alone.
4. When we first run an application from our product Windows Installer detects
the missing component(s) and triggers a repair.
5. The repair initiates using the cached MSI under C:\Windows\Installer.
However, when it comes time to replace the missing component:
i. it looks like the Windows Installer does another search for the MSI that
contains the component (bizarre)
ii. fails to find the original copy as it's already been deleted
iii. finds the cached copy, which is already executing; hence locked, and
pops up a dialog requesting the location of a source MSI file.
COME ON - THIS MUST TO BE A BUG
I have attached the full repair log, and snippets of what I thought were
interesting below with my comments surround in square brackets. I would
appreciate any feedback and possible work around. I would presume (many) others
would've come across something like this before.
[Cached copy of installer found]
Original package == C:\Windows\Installer\14a4210d.msi
Package we're running from == C:\Windows\Installer\14a4210d.msi
[Not sure if this is a problem but seems weird to me]
MSI (s) (20:54) [07:32:29:318]: APPCOMPAT: looking for appcompat database entry
with ProductCode '{FA2B343E-75B9-4EBB-A1C6-974E3B55775E}'.
MSI (s) (20:54) [07:32:29:318]: APPCOMPAT: no matching ProductCode found in
database.
MSI (s) (20:54) [07:32:29:709]: Package name retrieved from configuration data:
'IPFX Server Install.msi'
[Repairing around here]
[Time to replace missing component - this is when things go south]
MSI (s) (20:54) [07:34:16:569]: Executing op:
RegisterSharedComponentProvider(,,File=servicemanager.exe,Component={C750EF8F-87DA-4610-8658-8C513E1F8529},ComponentVersion=6.3.211.0,ProductCode={FA2B343E-75B9-4EBB-A1C6-974E3B55775E},ProductVersion=6.3.211,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0)
MSI (s) (20:54) [07:34:16:569]: Executing op:
FileCopy(SourceName=SERVIC~1.EXE|servicemanager.exe,SourceCabKey=servicemanager.exe,DestName=servicemanager.exe,Attributes=16384,FileSize=3023656,PerTick=65536,,VerifyMedia=1,CheckCRC=0,Version=6.3.211.0,Language=5129,InstallMode=59113472,,,)
MSI (s) (20:54) [07:34:16:585]: File: C:\VMLocal\servicemanager.exe; To be
installed; Won't patch; No existing file
MSI (s) (20:54) [07:34:16:600]: Resolving source.
MSI (s) (20:54) [07:34:16:600]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (20:54) [07:34:16:600]: User policy value 'DisableMedia' is 0
MSI (s) (20:54) [07:34:16:600]: Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Media enabled only if package is
safe.
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Looking for sourcelist for product
{FA2B343E-75B9-4EBB-A1C6-974E3B55775E}
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Adding
{FA2B343E-75B9-4EBB-A1C6-974E3B55775E}; to potential sourcelist list
(pcode;disk;relpath).
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Now checking product
{FA2B343E-75B9-4EBB-A1C6-974E3B55775E}
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Media is enabled for product.
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Attempting to use LastUsedSource
from source list.
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Trying source
C:\Users\shanep\AppData\Local\Temp\.
[The original copy which no longer exists]
MSI (s) (20:54) [07:34:16:600]: Note: 1: 2203 2:
C:\Users\shanep\AppData\Local\Temp\IPFX Server Install.msi 3: -2147287038
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Source is invalid due to
missing/inaccessible package.
MSI (s) (20:54) [07:34:16:600]: Note: 1: 1706 2: -2147483647 3: IPFX Server
Install.msi
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Processing net source list.
MSI (s) (20:54) [07:34:16:600]: Note: 1: 1706 2: -2147483647 3: IPFX Server
Install.msi
MSI (s) (20:54) [07:34:16:600]: SOURCEMGMT: Processing media source list.
MSI (s)
