Re: [WiX-users] intermittent WriteIIS7ConfigChanges failure on read webDir webkey
We are hitting this more frequently. By the way, the error message saying about webDir, but we only use webVirtualDir element in the authoring. - Original Message - From: Zhisheng Huang To: Zhisheng Huang ; John Cooper ; General discussion for Windows Installer XML toolset. ; General discussion for Windows Installer XML toolset. Cc: Sent: Wednesday, November 16, 2011 11:30 PM Subject: Re: [WiX-users] intermittent WriteIIS7ConfigChanges failure on read webDir webkey Any suggestion what could be wrong? I found in this forum that users hit different kind of errors with WriteIIS7ConfigChanges with error code 0x80070103, which means ERROR_NO_MORE_ITEMS What does this error indicate in this context? - Original Message - From: Zhisheng Huang To: John Cooper ; General discussion for Windows Installer XML toolset. Cc: Sent: Tuesday, November 15, 2011 11:28 AM Subject: Re: [WiX-users] intermittent WriteIIS7ConfigChanges failure on read webDir webkey Here is the WebSite element defined. There is no IP attribute specified explicitly. This setup code works fine with WIX30. This problem shows up only after we change to use WIX35 to compile the setup. - Original Message - From: John Cooper To: Zhisheng Huang ; General discussion for Windows Installer XML toolset. Cc: Sent: Tuesday, November 15, 2011 6:45 AM Subject: RE: [WiX-users] intermittent WriteIIS7ConfigChanges failure on read webDir webkey You must have a WebSite element with an Id of "DefaultWebSite" somewhere with a child WebAddress element. What is in that authoring? I get errors like this when the IP attribute is specified but is blank or whitespace. -- John Merryweather Cooper Jack Henry & Associates, Inc. Build & Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.com -Original Message- From: Zhisheng Huang [mailto:zhhuang5...@yahoo.com] Sent: Tuesday, November 15, 2011 1:32 AM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] intermittent WriteIIS7ConfigChanges failure on read webDir webkey HI, We are using WIX 3.5 RTM build and hit the following sproadically. ConfigureIIs7Exec: Error 0x80070057: Invalid web address. Port was not separated by a colon. ConfigureIIs7Exec: Error 0x80070057: Invalid web address. IP was not separated by a colon. ConfigureIIs7Exec: Error 0x80070057: Invalid web address. IP was not separated by a colon. ConfigureIIs7Exec: Error 0x80070057: Invalid web address. IP was not separated by a colon. WriteIIS7ConfigChanges: Error 0x80070103: Failed read webDir webkey WriteIIS7ConfigChanges: Error 0x80070103: Failed to configure IIS web svc ext. WriteIIS7ConfigChanges: Error 0x80070103: WriteIIS7ConfigChanges Failed. Here is the related WIX markup. Any idea why it fails to read webDir webkey? What is webDir webkey? (didn't find a good explanation) Thanks, Zhisheng -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use Burn to install new and minor upgrade
If you are strictly following the component rules, consider that during Major Upgrades with late scheduling of RemoveExistingProducts the following scenarios hold: - Upgraded components will be installed without removal of the obsoleted version of those components. - Unchanged components will be ignored/left alone by the upgrade. - IIRC, if you don't explicitly change any directory paths, already existing components will preserve their directories. - You can retrieve any already existing component's directory and set one of your directories to that location, thus preserving your customer's previous choices - You can still offer a different set of dialogs during upgrades than during initial installs. One technique I have seen is to install a service EXE that simply loads a DLL containing the service implementation. You update the DLL as needed between builds, and simply ship the same EXE binary in all builds. That way, you can update the code of the service while not having to reinstall the service on each upgrade. -Blair -Original Message- From: Michael Janulaitis [mailto:wix-u...@cornerbowl.com] Sent: Wednesday, November 23, 2011 11:16 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How to use Burn to install new and minor upgrade I've been at this for a few days now and it seems there is no way to create a bootstrapper that correctly launches msiexec for new installs and minor upgrades. Everyone seems to say not to use minor upgrades and instead do a major upgrade (then this wouldn't be a problem) but that is realistically not a user friendly option. First my installs install windows services which typically require domain admin credentials. Next many of my customers install to non-standard folders. So if I force a major upgrade then the users have to reset both the windows service credentials and possible keep re-pointing to their non-standard install directory. Installs are released weekly...not an option. So is my only solution InstallShield? It seems so. Please someone prove me wrong. Someone has to have tackled this problem. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CreateFolder is not creating required directory structure ...
The WiX documentation itself has a page on logging: How To Guides\Others\Get a log of your installation for debugging The online version of that page is here: http://wix.sourceforge.net/manual-wix3/get_a_log.htm It is instructive to read the logs sequentially as it allows you to see the flow that the engine takes and the timing of the setting of different values/properties. When I looked at your source code, here is the hierarchy I saw (shown as identifier\name of folder under parent): TARGETDIR\SourceDir - Required "root" of the hierarchy ProgramFilesFolder - Initial path is set by MSI - does not use its parent OneSpatial\1Spatial INSTALLDIR\dam ComDir\com ConfigDir\config ExeDir\exe AppDataFolder - Initial path is set by MSI - does not use its parent OneSpatialAppData\1Spatial GOTH_DATAROOT\data GOTH_DAM\dam GOTH_DAM_LOG\log GOTH_LIC\lic GOTH_ODBD_SORT\sort GOTH_OBDB_ROOT\odbd GOTH_ODBD_CONFIG\config GOTH_ODBD_DEFAULT\default GOTH_ODBD_HISTORY\history GOTH_ODBD_LOCK\lock GOTH_ODBD_OBJIDX\objidx GOTH_ODBD_OBJECT\reg Directory identifier values are session properties. If those properties exist before the CostFinalize, the corresponding values are used for those directories. Properties are then created for each directory to reflect each of their paths, so that they can be used in other tables or CAs and/or verified in CAs/logs. Assuming that NO properties are passed on either the installation command-line or via the build system, and assuming a 32-bit Windows 7 "standard" installation (AppDataFolder is in a different location on XP and downlevel), this is my quick determination of where I expect your MSI to place each of the above directories when the product was not previously installed and no properties are passed in via the command line nor changed by the UI: TARGETDIR = root folder of hard drive with the largest free space at time of installation ProgramFilesFolder = C:\Program Files\ OneSpatial = C:\Program Files\1Spatial\ INSTALLDIR = C:\Program Files\1Spatial\dam\ ComDir = C:\Program Files\1Spatial\dam\com\ ConfigDir = C:\Program Files\1Spatial\dam\config\ ExeDir = C:\Program Files\1Spatial\dam\exe\ AppDataFolder = C:\Users\\AppData\Roaming\ OneSpatialAppData = C:\Users\\AppData\Roaming\1Spatial\ GOTH_DATAROOT = $(env.SystemDrive)\1Spatial\data\ GOTH_DAM = $(env.SystemDrive)\1Spatial\data\dam\ GOTH_DAM_LOG = $(env.SystemDrive)\1Spatial\data\dam\log\ GOTH_LIC = $(env.SystemDrive)\1Spatial\data\lic\ GOTH_ODBD_SORT = $(env.SystemDrive)\1Spatial\data\sort\ GOTH_OBDB_ROOT = $(env.SystemDrive)\1Spatial\data\odbd\ GOTH_ODBD_CONFIG = $(env.SystemDrive)\1Spatial\data\odbd\config\ GOTH_ODBD_DEFAULT = $(env.SystemDrive)\1Spatial\data\odbd\default\ GOTH_ODBD_HISTORY = $(env.SystemDrive)\1Spatial\data\odbd\history\ GOTH_ODBD_LOCK = $(env.SystemDrive)\1Spatial\data\odbd\lock\ GOTH_ODBD_OBJIDX = $(env.SystemDrive)\1Spatial\data\odbd\objidx\ GOTH_ODBD_OBJECT = $(env.SystemDrive)\1Spatial\data\odbd\reg\ *NOTE: $(env.SystemDrive) is the root folder of the system drive of the system building the MSI file, NOT the system installing the MSI. While most Windows 7 installations use a system drive value of C:\, that is by no means universal and is NOT required on any version of Windows as far as I know. The corresponding MSI property would be [WindowsVolume], which already contains the backslash, if you need the corresponding path on the system you are installing on. Note that all identifier names that are in all CAPS can be placed anywhere by whomever installs your MSI, (parent/sibling relationships do not have to be honored), so if there are any required sibling relationships, the corresponding identifiers should not have been made public (all CAPS). Compare the above expected values with the values found in the verbose log, and investigate where/how those values are set. Also, check the action states of all components containing CreateFolder elements. Blair -Original Message- From: mat_macwilliam [mailto:marcus.macwill...@1spatial.com] Sent: Wednesday, November 30, 2011 2:18 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CreateFolder is not creating required directory structure ... Blair, I am a complete novice to this. The person who originally wrote our XML is no longer at the company. How do I get complete logging information out of the MSI when it is run? Incidentally the directory struc
Re: [WiX-users] Is major update supposed to duplicate the add/remove programs entry?
You cannot make a new MSI file with a new ProductCode, run it and expect that it will just update your existing files. You've changed the ProductCode, making it a completely different product so yes you get two entries in ARP. The other replies cover this anyway, but if you go the major upgrade route with upgrade elements etc it just works, replacing the older installed product with the new one. This is completely automatic and doesn't prompt for the user to uninstall the old one. It sounds like that's what you want. Phil Wilson -Original Message- From: Robert Lee [mailto:genrobert...@gmail.com] Sent: Wednesday, November 30, 2011 3:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is major update supposed to duplicate the add/remove programs entry? I would like to develop an installer so that it would NOT force the user to uninstall the application manually prior to installing new version. Just running the new msi should update everything automatically. As far as I understood the wix book, in order to achieve that, I should set product ID in the markup to "*", keep the upgrade code, and increase version number. But when I run the new msi, a new entry is added to add/remove programs. How to prevent that? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Error when launching CA from MSM
Hi,
I've created an MSM project which executes a Custom Action.. however
having hooked the MSM into a Setup project, during the installation if
fails with the following error...
CustomAction RegisterAddIn returned actual error code 1154 (note
this may not be 100% accurate if translation happened inside sandbox)
Error 1723. There is a problem with this Windows Installer package. A
DLL required for this install to complete could not be run. Contact your
support personnel or package vendor. Action RegisterAddIn, entry:
RegisterAddin, library: C:\Windows\Installer\MSI9DDB.tmp
Oddly if I reference the CA from the setup proj directly its fine.
I've replicated this issue in a very simple installation package... the
bare nuts of which I've included below...
Can anyone suggest what I'm missing??
Code example
** Custom action **
[CustomAction]
public static ActionResult RegisterAddIn(Session session)
{
session.Log("Begin CustomAction1");
return ActionResult.Success;
}
** Merge Module Project **
http://schemas.microsoft.com/wix/2006/wi";>
... Add a dummy component i.e. text file
** Setup Project **
http://schemas.microsoft.com/wix/2006/wi";>
WiX Version : 3.5
OS : Windows 7 x64
-
This email is sent on behalf of Northgate Information Solutions Limited and its
associated companies ("Northgate") and is strictly confidential and intended
solely for the addressee(s).
If you are not the intended recipient of this email you must: (i) not disclose,
copy or distribute its contents to any other person nor use its contents in any
way or you may be acting unlawfully; (ii) contact Northgate immediately on +44
(0)1442 232424 quoting the name of the sender and the addressee then delete it
from your system.
Northgate has taken reasonable precautions to ensure that no viruses are
contained in this email, but does not accept any responsibility once this email
has been transmitted. You should scan attachments (if any) for viruses.
Northgate Information Solutions Limited. Registered in England no. 06442582 -
Northgate Information Solutions UK Limited. Registered in England no. 968498 -
NorthgateArinso UK Limited .Registered in England no. 1587537 - Moorepay
Limited. Registered in England no. 891686 - First Business Support Limited.
Registered in England no. 3056267 - Registered Office: Peoplebuilding 2,
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire HP2 4NW
Northgate Managed Services Limited (NI). Registered in Northern Ireland no.
NI032979 - LearnServe Limited (NI). Registered in Northern Ireland no.
NI043825
Registered Office: Hillview House, 61 Church Road, Newtownabbey, Co. Antrim,
BT36 7LQ
-
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is major update supposed to duplicate the add/removeprograms entry?
The simplest way to implement a major upgrade is, as you say, put * for product code, keep the upgrade code and increment the product version. Then just add: That automatically adds the RemoveExistingProducts action and the appropriate Upgrade table entries and prevents downgrades too. -Original Message- From: Robert Lee [mailto:genrobert...@gmail.com] Sent: 30 November 2011 23:12 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Is major update supposed to duplicate the add/removeprograms entry? I would like to develop an installer so that it would NOT force the user to uninstall the application manually prior to installing new version. Just running the new msi should update everything automatically. As far as I understood the wix book, in order to achieve that, I should set product ID in the markup to "*", keep the upgrade code, and increase version number. But when I run the new msi, a new entry is added to add/remove programs. How to prevent that? - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
