Re: [WiX-users] Error 1923 - Service fails to install during upgrade
Hey thanks for this information! Here is the sdshow result for the service i.e. if I am reading it right localsystem, built-in admins, interactive users, service logon user has permissions on it, right? Don't see the SID trusted installer (please correct me if I am missing anything here). D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) Thanks, Sandip -Original Message- From: Heath Stewart Sent: Tuesday, June 11, 2013 2:42 PM To: Sandip Shahane; General discussion for Windows Installer XML toolset. Cc: Marc Reyhner; Doug Bradley; Vitaly Voloshin Subject: RE: [WiX-users] Error 1923 - Service fails to install during upgrade Run: sc sdshow HealthService If SID S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 owns the service, it can only be updated by TrustedInstaller (Windows update system). Heath Stewart VS Pro Deployment Experience, Microsoft http://blogs.msdn.com/heaths -Original Message- From: Sandip Shahane Sent: Monday, June 10, 2013 1:55 PM To: General discussion for Windows Installer XML toolset. Cc: Marc Reyhner; Doug Bradley; Vitaly Voloshin; Heath Stewart Subject: RE: [WiX-users] Error 1923 - Service fails to install during upgrade That's what I also suspected earlier but cannot point finger to any such errors. StopServices action doesn't give any indication of failure. We are noticing this issue sometimes even when the service is stopped manually before running upgrade. Is there anything particular in the setup log that could tell if the service was marked for deletion and disabled while uninstalling? I have also copied Heath who thinks it could be related to the MSI not able to write to TrustedInstaller resources. Heath, is there a way to identify if this indeed is the case? Thanks, Sandip -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, June 07, 2013 8:47 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Error 1923 - Service fails to install during upgrade What does the StopServices action say about stopping the failing service? There may be something useful there. If you have any code in your apps that starts, stops, reconfigures these services, then take a close look at it. One of the reasons for this issue is that somebody had a handle open to the service when it was being uninstalled, so it gets marked for deletion and disabled. Windows can't install it when it's in that state. I think the MMC services snapin had that bug for a while, and if it's still there them monitoring the situation using that snapin is probably making it worse ;) I'd expect an authoring issue to affect all the services, and be more consistent across machines. Phil -Original Message- From: Sandip Shahane [mailto:sandi...@microsoft.com] Sent: Thursday, June 06, 2013 2:46 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error 1923 - Service fails to install during upgrade Hi WIX experts, We are noticing error 1923 as below during upgrade of our product. The repro is not consistent but hitting it with very high frequency. So far, we are seeing it happening on both Win2012 and Win2012 R2 machines. The service installs fine during fresh and repair installation, but fails only during upgrade. The MSI package runs as per-machine and user running upgrade is an administrator on the machine. I don't find any apparent errors about service install failure in the event log, so no clue what the problem is. Heath Stewart mentioned on another forum that this looks to be to do with MSI not able to write to TrustedInstaller resources and is a WIX authoring issue. Could you kindly let me know what the issue with WIX authoring it is and how to fix it? Is this a known issue or if a bug needs to be opened for this issue for this issue? I am using WIX 3.7 and below is the WIX code snippet. Log snippets: MSI (s) (F0:20) [04:25:45:682]: MSI_LUA: Credential prompt not required, user is an admin MSI (s) (F0:20) [04:26:09:073]: Executing op: ProgressTotal(Total=3,Type=1,ByteEquivalent=130) MSI (s) (F0:20) [04:26:09:073]: Executing op: ServiceInstall(Name=HealthService,DisplayName=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10500,ImagePath=C:\Program Files\Monitoring Agent\Agent\HealthService.exe,ServiceType=32,StartType=2,ErrorControl=0,,De pendencies=rpcss[~][~][~],,,Password=**,Description=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10501,,) MSI (s) (F0:20) [04:26:09:088]: Executing op: ServiceInstall(Name=AdtAgent,DisplayName=@C:\Windows\system32\AdtAgent.exe,- 500,ImagePath=C:\Windows\system32\AdtAgent.exe,ServiceType=16,StartType=4,Er rorControl=1,,Dependencies=eventlog[~]dnscache[~][~][~],,StartName=NT AUTHORITY\NetworkService,Password=**,Description=@C:\Windows\system3 2\AdtAgent.exe,-501,,) Information
Re: [WiX-users] Error 1923 - Service fails to install during upgrade
That's what I also suspected earlier but cannot point finger to any such errors. StopServices action doesn't give any indication of failure. We are noticing this issue sometimes even when the service is stopped manually before running upgrade. Is there anything particular in the setup log that could tell if the service was marked for deletion and disabled while uninstalling? I have also copied Heath who thinks it could be related to the MSI not able to write to TrustedInstaller resources. Heath, is there a way to identify if this indeed is the case? Thanks, Sandip -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: Friday, June 07, 2013 8:47 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Error 1923 - Service fails to install during upgrade What does the StopServices action say about stopping the failing service? There may be something useful there. If you have any code in your apps that starts, stops, reconfigures these services, then take a close look at it. One of the reasons for this issue is that somebody had a handle open to the service when it was being uninstalled, so it gets marked for deletion and disabled. Windows can't install it when it's in that state. I think the MMC services snapin had that bug for a while, and if it's still there them monitoring the situation using that snapin is probably making it worse ;) I'd expect an authoring issue to affect all the services, and be more consistent across machines. Phil -Original Message- From: Sandip Shahane [mailto:sandi...@microsoft.com] Sent: Thursday, June 06, 2013 2:46 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error 1923 - Service fails to install during upgrade Hi WIX experts, We are noticing error 1923 as below during upgrade of our product. The repro is not consistent but hitting it with very high frequency. So far, we are seeing it happening on both Win2012 and Win2012 R2 machines. The service installs fine during fresh and repair installation, but fails only during upgrade. The MSI package runs as per-machine and user running upgrade is an administrator on the machine. I don't find any apparent errors about service install failure in the event log, so no clue what the problem is. Heath Stewart mentioned on another forum that this looks to be to do with MSI not able to write to TrustedInstaller resources and is a WIX authoring issue. Could you kindly let me know what the issue with WIX authoring it is and how to fix it? Is this a known issue or if a bug needs to be opened for this issue for this issue? I am using WIX 3.7 and below is the WIX code snippet. Log snippets: MSI (s) (F0:20) [04:25:45:682]: MSI_LUA: Credential prompt not required, user is an admin MSI (s) (F0:20) [04:26:09:073]: Executing op: ProgressTotal(Total=3,Type=1,ByteEquivalent=130) MSI (s) (F0:20) [04:26:09:073]: Executing op: ServiceInstall(Name=HealthService,DisplayName=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10500,ImagePath=C:\Program Files\Monitoring Agent\Agent\HealthService.exe,ServiceType=32,StartType=2,ErrorControl=0,,De pendencies=rpcss[~][~][~],,,Password=**,Description=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10501,,) MSI (s) (F0:20) [04:26:09:088]: Executing op: ServiceInstall(Name=AdtAgent,DisplayName=@C:\Windows\system32\AdtAgent.exe,- 500,ImagePath=C:\Windows\system32\AdtAgent.exe,ServiceType=16,StartType=4,Er rorControl=1,,Dependencies=eventlog[~]dnscache[~][~][~],,StartName=NT AUTHORITY\NetworkService,Password=**,Description=@C:\Windows\system3 2\AdtAgent.exe,-501,,) Information 1923.Service '@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10500' (HealthService) could not be installed. Verify that you have sufficient privileges to install system services. MSI (s) (F0:20) [04:26:09:088]: Executing op: ServiceInstall(Name=System Center Management APM,DisplayName=@C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,-100,ImagePath=C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,ServiceType=16,StartType=4,Erro rControl=1,,Dependencies=RPCSS[~][~][~],,StartName=LocalSystem,Password= **,Description=@C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,-501,,) ... ... ... Property(N): AdminUser = 1 Property(N): MsiTrueAdminUser = 1 ServiceInstall and ServiceControl entries in WIX source for this service looks like below: ServiceInstall Id=MOMHealthServiceInstall Name=HealthService DisplayName=[HEALTH_SERVICE_DISPLAY_NAME] Type=shareProcess Start=auto ErrorControl=ignore Description=[HEALTH_SERVICE_DESCRIPTION] ServiceDependency Id=rpcss / /ServiceInstall ServiceControl Id=HealthServiceRemoveUninstall Name=HealthService Remove=uninstall Wait=yes / ServiceControl Id=HealthServiceStopBoth Name
[WiX-users] Error 1923 - Service fails to install during upgrade
Hi WIX experts, We are noticing error 1923 as below during upgrade of our product. The repro is not consistent but hitting it with very high frequency. So far, we are seeing it happening on both Win2012 and Win2012 R2 machines. The service installs fine during fresh and repair installation, but fails only during upgrade. The MSI package runs as per-machine and user running upgrade is an administrator on the machine. I don't find any apparent errors about service install failure in the event log, so no clue what the problem is. Heath Stewart mentioned on another forum that this looks to be to do with MSI not able to write to TrustedInstaller resources and is a WIX authoring issue. Could you kindly let me know what the issue with WIX authoring it is and how to fix it? Is this a known issue or if a bug needs to be opened for this issue for this issue? I am using WIX 3.7 and below is the WIX code snippet. Log snippets: MSI (s) (F0:20) [04:25:45:682]: MSI_LUA: Credential prompt not required, user is an admin MSI (s) (F0:20) [04:26:09:073]: Executing op: ProgressTotal(Total=3,Type=1,ByteEquivalent=130) MSI (s) (F0:20) [04:26:09:073]: Executing op: ServiceInstall(Name=HealthService,DisplayName=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10500,ImagePath=C:\Program Files\Monitoring Agent\Agent\HealthService.exe,ServiceType=32,StartType=2,ErrorControl=0,,Dependencies=rpcss[~][~][~],,,Password=**,Description=@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10501,,) MSI (s) (F0:20) [04:26:09:088]: Executing op: ServiceInstall(Name=AdtAgent,DisplayName=@C:\Windows\system32\AdtAgent.exe,-500,ImagePath=C:\Windows\system32\AdtAgent.exe,ServiceType=16,StartType=4,ErrorControl=1,,Dependencies=eventlog[~]dnscache[~][~][~],,StartName=NT AUTHORITY\NetworkService,Password=**,Description=@C:\Windows\system32\AdtAgent.exe,-501,,) Information 1923.Service '@C:\Program Files\Monitoring Agent\Agent\HealthService.dll,-10500' (HealthService) could not be installed. Verify that you have sufficient privileges to install system services. MSI (s) (F0:20) [04:26:09:088]: Executing op: ServiceInstall(Name=System Center Management APM,DisplayName=@C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,-100,ImagePath=C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,ServiceType=16,StartType=4,ErrorControl=1,,Dependencies=RPCSS[~][~][~],,StartName=LocalSystem,Password=**,Description=@C:\Program Files\Monitoring Agent\Agent\APMDOTNETAgent\InterceptSvc.exe,-501,,) ... ... ... Property(N): AdminUser = 1 Property(N): MsiTrueAdminUser = 1 ServiceInstall and ServiceControl entries in WIX source for this service looks like below: ServiceInstall Id=MOMHealthServiceInstall Name=HealthService DisplayName=[HEALTH_SERVICE_DISPLAY_NAME] Type=shareProcess Start=auto ErrorControl=ignore Description=[HEALTH_SERVICE_DESCRIPTION] ServiceDependency Id=rpcss / /ServiceInstall ServiceControl Id=HealthServiceRemoveUninstall Name=HealthService Remove=uninstall Wait=yes / ServiceControl Id=HealthServiceStopBoth Name=HealthService Stop=both Wait=yes / Thanks, Sandip -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] patch install error 2247 1636 while adding a new component to the patch.
I am getting below error when trying to install a patch that has added a new
component (2 files). When looked from orca it appears to add the 2 files just
fine. Also if I add the new files to existing component instead of adding a new
component, it seems to be installing fine.
Additional information:
1. I am using WIX 3 toolset to generate patch. Original MSI and the
updated one is built using WIX 2.0
2. We have another MSI that and we have added components via it's patch,
that one seems to be working just fine. It's just this MSI that has the below
issue.
3. I also tried using WIX 3.5 to generate patch and that too is failing
with same error.
What is the problem here and how do I fix it? Do I need to open a bug for this
if this isn't already a known issue? Let me know if you need more info on this.
Patch Install error:
=== Verbose logging started: 2/1/2012 13:56:08 Build type: SHIP UNICODE
5.00.7601.00 Calling process: C:\Windows\System32\msiexec.exe ===
MSI (c) (84:64) [13:56:08:703]: Font created. Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (84:64) [13:56:08:704]: Font created. Charset: Req=0, Ret=0, Font:
Req=MS Shell Dlg, Ret=MS Shell Dlg
MSI (c) (84:70) [13:56:08:737]: Resetting cached policy values
MSI (c) (84:70) [13:56:08:737]: Machine policy value 'Debug' is 0
MSI (c) (84:70) [13:56:08:737]: *** RunEngine:
*** Product: {PRODUCT-CODE-GUID}
*** Action:
*** CommandLine: **
MSI (c) (84:70) [13:56:08:739]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (84:70) [13:56:08:845]: Cloaking enabled.
MSI (c) (84:70) [13:56:08:845]: Attempting to enable all disabled privileges
before calling Install on Server
MSI (c) (84:70) [13:56:08:857]: End dialog not enabled
MSI (c) (84:70) [13:56:08:858]: Original package ==
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:858]: Package we're running from ==
C:\Windows\Installer\241bb396.msi
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall Flags override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall VersionNT override found.
MSI (c) (84:70) [13:56:08:861]: APPCOMPAT: Uninstall ServicePackLevel override
found.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: looking for appcompat database entry
with ProductCode '{PRODUCT-CODE-GUID}'.
MSI (c) (84:70) [13:56:08:862]: APPCOMPAT: no matching ProductCode found in
database.
MSI (c) (84:70) [13:56:08:872]: MSCOREE not loaded loading copy from system32
MSI (c) (84:70) [13:56:08:880]: Original patch == C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:880]: Patch we're running from ==
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY: Verifying patch
-- 'C:\acs\KB1234567-x64-ABC.msp' against software restriction policy
MSI (c) (84:70) [13:56:08:881]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (84:70) [13:56:08:881]: SOFTWARE RESTRICTION POLICY:
C:\acs\KB1234567-x64-ABC.msp is not digitally signed
MSI (c) (84:70) [13:56:08:883]: SOFTWARE RESTRICTION POLICY:
C:\acs\KB1234567-x64-ABC.msp is permitted to run at the 'unrestricted'
authorization level.
MSI (c) (84:70) [13:56:08:884]: SequencePatches starts. Product code:
{PRODUCT-CODE-GUID}, Product version: 6.1.7221.0, Upgrade code:
{UPGRADE-CODE-GUID}, Product language 1033
MSI (c) (84:70) [13:56:08:884]: PATCH SEQUENCER: verifying the applicability of
QFE patch C:\acs\KB1234567-x64-ABC.msp against product code:
{PRODUCT-CODE-GUID}, product version: 6.1.7221.0, product language 1033 and
upgrade code: {UPGRADE-CODE-GUID}
MSI (c) (84:70) [13:56:08:885]: PATCH SEQUENCER: QFE patch
C:\acs\KB1234567-x64-ABC.msp is applicable.
MSI (c) (84:70) [13:56:08:887]: SequencePatches returns success.
MSI (c) (84:70) [13:56:08:887]: Final Patch Application Order:
MSI (c) (84:70) [13:56:08:887]: {E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} -
C:\acs\KB1234567-x64-ABC.msp
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisablePatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (84:70) [13:56:08:887]: Machine policy value 'DisableFlyWeightPatching'
is 0
MSI (c) (84:70) [13:56:08:887]: Turning off patch optimization.
{E0B517BB-1A9E-4FDF-9D87-95BD35F21BE3} patch is not authored to support it.
MSI (c) (84:70) [13:56:08:887]: Looking for patch transform: RTM.1
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (c) (84:70) [13:56:08:887]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Feature 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Error 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2262 2: Binary 3: -2147287038
MSI (c) (84:70) [13:56:08:888]: Note: 1: 2247 2: 3: 4:
DEBUG: Error 2247: Database: Transform stream read/write failure.
1: 2247 2: 3:
Re: [WiX-users] Where can I get the symbols for WIX 3.0 RTM?
Hey internal site http://wix should have the details for binaries, sources and symbols. I had enlisted wix 3.0 RTM tree some time back. -Original Message- From: Sharat Janapareddy [mailto:sharat.janapare...@microsoft.com] Sent: Tuesday, March 16, 2010 3:53 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Where can I get the symbols for WIX 3.0 RTM? Can someone point me to the symbols for WIX 3.0 RTM sources? I don't see anything related to that @ http://sourceforge.net/projects/wix/files/. Thanks, Sharat Janapareddy ~ 40269 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Recall: Where can I get the symbols for WIX 3.0 RTM?
Sandip Shahane would like to recall the message, Where can I get the symbols for WIX 3.0 RTM?. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Resending: DigitalCertificateRef element deprecated in WIX 3.0?
Resending... Is there any replacement for this element or alternative to achieve the same result as I used to do prior to WIX 3.0 Thanks, Sandip -Original Message- From: Sandip Shahane [mailto:sandi...@microsoft.com] Sent: Thursday, September 17, 2009 12:16 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] DigitalCertificateRef element deprecated in WIX 3.0? Seems like DigitalCertificateRef element is deprecated in WIX 3.0. My question is there any replacement for this element? We are getting bunch of errors like for the code snippet shown below with WIX 3.0 toolset which used to build fine with WIX 2.0: error CNDL0005 : The Media element contains an unexpected child element 'DigitalCertificate'. (Fixed this error by making this element child of DigitalSignature) error CNDL0005 : The Media element contains an unexpected child element 'DigitalCertificateRef'. (Not sure how to fix this one...) We have entries added to MSIDigitalCertificate Table by WIX code as below and in order to avoid duplicate entries in this table for each Media entry I am using DigigitalCertificateRef. This way each signature references the same certificate row rather than creating a new one. Media Id=1 DiskPrompt=1 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab1.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificate Id=MyCodeSigningId SourceFile=mscodesign.cer / ?endif ? /Media Media Id=2 DiskPrompt=2 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab2.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificateRef Id= MyCodeSigningId / ?endif ? /Media Media Id=3 DiskPrompt=3 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab3.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificateRef Id= MyCodeSigningId / ?endif ? /Media -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DigitalCertificateRef element deprecated in WIX 3.0?
Seems like DigitalCertificateRef element is deprecated in WIX 3.0. My question is there any replacement for this element? We are getting bunch of errors like for the code snippet shown below with WIX 3.0 toolset which used to build fine with WIX 2.0: error CNDL0005 : The Media element contains an unexpected child element 'DigitalCertificate'. (Fixed this error by making this element child of DigitalSignature) error CNDL0005 : The Media element contains an unexpected child element 'DigitalCertificateRef'. (Not sure how to fix this one...) We have entries added to MSIDigitalCertificate Table by WIX code as below and in order to avoid duplicate entries in this table for each Media entry I am using DigigitalCertificateRef. This way each signature references the same certificate row rather than creating a new one. Media Id=1 DiskPrompt=1 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab1.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificate Id=MyCodeSigningId SourceFile=mscodesign.cer / ?endif ? /Media Media Id=2 DiskPrompt=2 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab2.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificateRef Id= MyCodeSigningId / ?endif ? /Media Media Id=3 DiskPrompt=3 EmbedCab=no CompressionLevel=$(var.CabCompressionLevel) Cabinet=Cab3.Cab VolumeLabel=DISK1 ?if $(env.WIX_IS_SIGNED_BUILD) != 0 ? DigitalCertificateRef Id= MyCodeSigningId / ?endif ? /Media -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] file sequencing
Thanks Heath, I will take a look using torch.exe, and also update the sequence post build and see how it goes. - Sandip From: Heath Stewart Sent: Monday, June 23, 2008 7:44 PM To: Sandip Shahane; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: RE: file sequencing Actually, it can if you use run torch.exe against the target and upgrade MSIs. Peter should have some examples on his blog at http://blogs.msdn.com/pmarcu. What ends up happening is that everything that is referenceable (features, components, directories, etc.) gets put into a separate section automatically then you reference everything you want in your patch families. The file sequence is automatically handled. The problem with PatchWiz is that it doesn’t handle changed file sequences between target and upgraded MSIs and, thus, won’t increment them to the correct sequence (above the last sequence in the RTM’s File table). You could always implement some post-processing script to copy the File.Sequence column based on the File.File key column. Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 18, 2008 4:00 PM To: Heath Stewart; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: RE: file sequencing Thanks Heath, but unfortunately wix 3.0 Patch does not seem to support patching files from MSMs ( http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12785.html ) and going to wixlibs from MSM now means a complete overhaul of setup. I am pretty sure something has changed on our build system or in Wix code and debugging the light may give some idea.. Thanks and Regards, Sandip From: Heath Stewart Sent: Wednesday, June 18, 2008 1:17 PM To: Sandip Shahane; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: RE: file sequencing I recommend using the new patching built into WiX v3. See the documentation for the Patch element. There’s also some examples of building a patch using this new infrastructure in wix.chm. In this case, maintaining file sequences doesn’t matter. Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 18, 2008 12:13 PM To: WiX-users@lists.sourceforge.net Cc: Heath Stewart; Anandha Ganesan Subject: file sequencing Hello, I am facing a strange issue here and any help to figure out what is happening will be greatly appreciated. We released our product SP1 (build 6.0.6278.) and then started work on SP2 build after few builds I noticed the file sequencing has changed in the File table. Tracing back to old builds the number of files and sequence till SP2 build 6.0.6316 was exactly same as that released SP1 build, but the filesequence suddenly changed in build 6.0.6317, though the number of files were same in this build. Looking at our source code there has not been any change in the wix scripts ( no new files, removal of files, re-org or anything ) that could have affected the file ordering in File table. We are using Wix to build the MSIs (candle and light versions is 2.0.4409.0 ) Is there any reason why this sudden change of file ordering might have happened and any work around for this? (We did not either change the wix toolset between these builds.) Looking at the wix code base looks like the rows are created and maintained using ICollection typed object (for e.g. FileMediaInformationCollection) and I suspect either sorting mechanism in wix or .net implementation can affect this change in behavior (or I could be missing something here). As a result of this when we create a patch with delta between SP1 and SP2 it gives error 1334 during patch application. We faced this issue earlier and it was because we had mistakenly added files in existing mergemodule and in the same media; adding files to separate merge modules and on different media had restored the file sequencing. But this time we have not added any file to the MSI. Using patch group can preserve the file sequence but I read on this group that patch groups does not help for file sequencing in case we are using merge modules and we in this case I am using merge modules here. Any pointers to solve this or explaining how file sequencing works ( or if you can point to the code) would be greatly appreciated. Thanks, Sandip - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] file sequencing
Yes I am using Wix V2 (file version of candle and light 2.0.4409.0). Is there any recommended version of .Net framework for Wix V2? Thanks, Sandip -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Wednesday, June 18, 2008 5:01 PM To: General discussion for Windows Installer XML toolset.; Heath Stewart Cc: Anandha Ganesan Subject: Re: [WiX-users] file sequencing What version of the WiX toolset are you using? There are reports that changing the .NET Framework version changes the sort order in WiX v2. WiX v3 is not affected by this problem because the sorting algorithm was changed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandip Shahane Sent: Wednesday, June 18, 2008 16:00 To: Heath Stewart; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: Re: [WiX-users] file sequencing Thanks Heath, but unfortunately wix 3.0 Patch does not seem to support patching files from MSMs ( http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12785.html ) and going to wixlibs from MSM now means a complete overhaul of setup. I am pretty sure something has changed on our build system or in Wix code and debugging the light may give some idea.. Thanks and Regards, Sandip From: Heath Stewart Sent: Wednesday, June 18, 2008 1:17 PM To: Sandip Shahane; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: RE: file sequencing I recommend using the new patching built into WiX v3. See the documentation for the Patch element. There’s also some examples of building a patch using this new infrastructure in wix.chm. In this case, maintaining file sequences doesn’t matter. Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 18, 2008 12:13 PM To: WiX-users@lists.sourceforge.net Cc: Heath Stewart; Anandha Ganesan Subject: file sequencing Hello, I am facing a strange issue here and any help to figure out what is happening will be greatly appreciated. We released our product SP1 (build 6.0.6278.) and then started work on SP2 build after few builds I noticed the file sequencing has changed in the File table. Tracing back to old builds the number of files and sequence till SP2 build 6.0.6316 was exactly same as that released SP1 build, but the filesequence suddenly changed in build 6.0.6317, though the number of files were same in this build. Looking at our source code there has not been any change in the wix scripts ( no new files, removal of files, re-org or anything ) that could have affected the file ordering in File table. We are using Wix to build the MSIs (candle and light versions is 2.0.4409.0 ) Is there any reason why this sudden change of file ordering might have happened and any work around for this? (We did not either change the wix toolset between these builds.) Looking at the wix code base looks like the rows are created and maintained using ICollection typed object (for e.g. FileMediaInformationCollection) and I suspect either sorting mechanism in wix or .net implementation can affect this change in behavior (or I could be missing something here). As a result of this when we create a patch with delta between SP1 and SP2 it gives error 1334 during patch application. We faced this issue earlier and it was because we had mistakenly added files in existing mergemodule and in the same media; adding files to separate merge modules and on different media had restored the file sequencing. But this time we have not added any file to the MSI. Using patch group can preserve the file sequence but I read on this group that patch groups does not help for file sequencing in case we are using merge modules and we in this case I am using merge modules here. Any pointers to solve this or explaining how file sequencing works ( or if you can point to the code) would be greatly appreciated. Thanks, Sandip - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open
[WiX-users] file sequencing
Hello, I am facing a strange issue here and any help to figure out what is happening will be greatly appreciated. We released our product SP1 (build 6.0.6278.) and then started work on SP2 build after few builds I noticed the file sequencing has changed in the File table. Tracing back to old builds the number of files and sequence till SP2 build 6.0.6316 was exactly same as that released SP1 build, but the filesequence suddenly changed in build 6.0.6317, though the number of files were same in this build. Looking at our source code there has not been any change in the wix scripts ( no new files, removal of files, re-org or anything ) that could have affected the file ordering in File table. We are using Wix to build the MSIs (candle and light versions is 2.0.4409.0 ) Is there any reason why this sudden change of file ordering might have happened and any work around for this? (We did not either change the wix toolset between these builds.) Looking at the wix code base looks like the rows are created and maintained using ICollection typed object (for e.g. FileMediaInformationCollection) and I suspect either sorting mechanism in wix or .net implementation can affect this change in behavior (or I could be missing something here). As a result of this when we create a patch with delta between SP1 and SP2 it gives error 1334 during patch application. We faced this issue earlier and it was because we had mistakenly added files in existing mergemodule and in the same media; adding files to separate merge modules and on different media had restored the file sequencing. But this time we have not added any file to the MSI. Using patch group can preserve the file sequence but I read on this group that patch groups does not help for file sequencing in case we are using merge modules and we in this case I am using merge modules here. Any pointers to solve this or explaining how file sequencing works ( or if you can point to the code) would be greatly appreciated. Thanks, Sandip - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] file sequencing
Thanks Heath, but unfortunately wix 3.0 Patch does not seem to support patching files from MSMs ( http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg12785.html ) and going to wixlibs from MSM now means a complete overhaul of setup. I am pretty sure something has changed on our build system or in Wix code and debugging the light may give some idea.. Thanks and Regards, Sandip From: Heath Stewart Sent: Wednesday, June 18, 2008 1:17 PM To: Sandip Shahane; WiX-users@lists.sourceforge.net Cc: Anandha Ganesan Subject: RE: file sequencing I recommend using the new patching built into WiX v3. See the documentation for the Patch element. There’s also some examples of building a patch using this new infrastructure in wix.chm. In this case, maintaining file sequences doesn’t matter. Heath Stewart Deployment Technology Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 18, 2008 12:13 PM To: WiX-users@lists.sourceforge.net Cc: Heath Stewart; Anandha Ganesan Subject: file sequencing Hello, I am facing a strange issue here and any help to figure out what is happening will be greatly appreciated. We released our product SP1 (build 6.0.6278.) and then started work on SP2 build after few builds I noticed the file sequencing has changed in the File table. Tracing back to old builds the number of files and sequence till SP2 build 6.0.6316 was exactly same as that released SP1 build, but the filesequence suddenly changed in build 6.0.6317, though the number of files were same in this build. Looking at our source code there has not been any change in the wix scripts ( no new files, removal of files, re-org or anything ) that could have affected the file ordering in File table. We are using Wix to build the MSIs (candle and light versions is 2.0.4409.0 ) Is there any reason why this sudden change of file ordering might have happened and any work around for this? (We did not either change the wix toolset between these builds.) Looking at the wix code base looks like the rows are created and maintained using ICollection typed object (for e.g. FileMediaInformationCollection) and I suspect either sorting mechanism in wix or .net implementation can affect this change in behavior (or I could be missing something here). As a result of this when we create a patch with delta between SP1 and SP2 it gives error 1334 during patch application. We faced this issue earlier and it was because we had mistakenly added files in existing mergemodule and in the same media; adding files to separate merge modules and on different media had restored the file sequencing. But this time we have not added any file to the MSI. Using patch group can preserve the file sequence but I read on this group that patch groups does not help for file sequencing in case we are using merge modules and we in this case I am using merge modules here. Any pointers to solve this or explaining how file sequencing works ( or if you can point to the code) would be greatly appreciated. Thanks, Sandip - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error 1334 due to file sequencing.
+wix-dev mailing list and setupsup Note that file sequencing was changed in SP1 (after RTM was released) for few files in one of the merge modules used. I fixed it so that the merge modules file sequencing is now exactly the same as before (though some merge modules have now additional files too at the end of sequencing in File Table). After integrating the merge module into MSI the sequencing seems to have changed. Why is this happening and how do I ensure the file sequencing is preserved on merging the modules. Thanks and Regards, Sandip From: Sandip Shahane Sent: Friday, September 07, 2007 4:58 PM To: 'wix-users@lists.sourceforge.net'; Windows Installer XML; Rob Mensching Subject: RE: error 1334 due to file sequencing. Hi, Is there any document on how wix creates the MSI generally and File table in particular. I am interested in understanding how the files are ordered in the File table by the Wix. I want to troubleshoot this issue I am facing (seems like it is similar to http://sourceforge.net/mailarchive/message.php?msg_id=E1FZMWn-0007MY-CR%40sc8-sf-web5.sourceforge.net ). We have RTM MSI built using Wix It is composed of few merge modules. Now we have built a SP of the same RTM with few new files and few file updates in the existing merge modules. Also we have added a merge module to the MSI. Now after reinstalling a feature we get error 1334 (file not found in cab). I noticed the file sequencing was changed so I went and did the changes to add PatchGroup attribute to all new files in the respective merge modules (with incremental PatchGroup value for each new file). But still files are not in correct order. Files ordering is changed even before I come across a new file in the File table. On comparing every merge module I observed existing files are in same order with additional files at the end of each merge modules. Also during SP1 we have changed the Package InstallerVersion='300' from InstallerVersion='200'. I have created patch using msimsp and provided FileSequencStart as sufficiently large number. Any guidance / pointers will be greatly appreciated as we are blocked here. Thanks and Regards, Sandip From: Sandip Shahane Sent: Friday, September 07, 2007 11:13 AM To: wix-users@lists.sourceforge.net; Windows Installer XML Subject: error 1334 due to file sequencing. I noticed that file sequencing was changed for few files in one of the merge modules used. I fixed it so that both the merge modules file sequencing is now exactly the same. But after integrating the merge module into MSI the sequencing seems to have changed. Why is this happening and how do I ensure the file sequencing is preserved on merging the modules. From: Hemchander Sannidhanam Sent: Thursday, September 06, 2007 1:15 PM To: Sandip Shahane; Windows Installer Support (MS Internal) Subject: RE: file sequencing... Unfortunately, there is no ICE to validate an MSP. To just give you an idea of the reason behind the 1334 error: 1. Windows Installer looks at an MSI (with all patches applied to its in-memory view of the RTM MSI) and goes through the files in the File table in a sequence sorted by the Sequence column of the File table. 2. For each of these files that needs to be updated or installed as part of this transaction, it creates a FileCopy (or PatchApply) opcode and queues it up in the installation script 3. When the Windows Installer's executor looks at the FileCopy (or PatchApply) opcode and realizes that the file is compressed, it goes looking inside the cab related to this file. 4. We extract files from the cab sequentially (not random access). This means if the files listed in the File table and the ones inside the cab are not in the same order, you will see this 1334 error. If you changed the File sequence numbers between your RTM and SP1, then the in-memory view of the MSI will have a File table whose sequence numbers might not match with that of the cab. This is the primary reason for the 1334 error while applying a patch. Hem. From: Sandip Shahane Sent: Tuesday, September 04, 2007 3:49 PM To: Windows Installer Support (MS Internal) Subject: file sequencing... Hi, How do we make sure the newly added files in an existing merge modules does not break MSI rule of file sequencing? We have several merge modules in our product setup (built using Wix) and most of them have new files added (we added PatchGroup attribute to newly added files and also added them as a separate components at the end of the component element list under Directory element). Now after upgrading the existing RTM product to this SP and doing reinstall of a feature it gives error 1334 (file not found in the cab). My understanding is this is due to file sequencing conflict (the orca shows few files in File table as changed only for Sequence column, rest all remaining same). I am not sure what else might be missing or need to do to make sure the file sequencing
Re: [WiX-users] error 1334 due to file sequencing.
True, this is what is happening, but what I can't figure out is why this is happening or is there anything I am doing wrong here. Can anybody tell if the following is indeed a bug and if so, is it fixed or any workaround? http://sourceforge.net/mailarchive/message.php?msg_id=E1FZMWn-0007MY-CR%40sc8-sf-web5.sourceforge.net My problem is exactly similar to this one. What I am looking for is some kind of log (build time) or trace that can point me to what is going wrong from my side. Here is what I see: There are few merge modules A,B,C,D etc.. There has been no change in first two merge modules, for third one the existing file sequence is same (as seen in the MSMs) with some new files at the end of the merge module (same is the case for other merge modules too). Now, I noticed on building the MSI that file sequence is changed for the existing files from merge module C (they are not obviously merged in the same order as in the MSM), which is something very strange. Here is the light.exe verbose log for files ordered as F_1, F_2, F_3, F_4 in the merged module. It's not in the same order as in the wix source files (.wxs). I want to understand how this ordering of the files is decided while building MSM and also merging into MSI ? Updating file information. Generating database. Merging modules. Processing media information. Cabbing file F_2 from 'c:\userTempLocation.41712086_AFA9_408D_84D8_5884F692B6CD'. Cabbing file F_1 from 'c:\userTempLocation.41712086_AFA9_408D_84D8_5884F692B6CD'. Cabbing file F_4 from 'c:\userTempLocation.41712086_AFA9_408D_84D8_5884F692B6CD'. Cabbing file F_3 from 'c:\userTempLocation.41712086_AFA9_408D_84D8_5884F692B6CD'. Thanks and Regards, Sandip From: Heath Stewart Sent: Monday, September 10, 2007 2:32 PM To: Sandip Shahane; Windows Installer Support (MS Internal); wix-users@lists.sourceforge.net; Windows Installer XML; Rob Mensching; [EMAIL PROTECTED] Subject: RE: error 1334 due to file sequencing. The why is because PatchWiz.dll (like when you use msimsp.exe) will automatically update the file sequences to begin the last sequence number of the target product (as authored in PCP files for older PatcWiz.dll, or automatically with newer versions of PatchWiz.dll). If those sequence numbers change in between the target and upgrade, PatchWiz.dll will not automatically update them so the new files sequences authored in (or merged in, in this case) are used. That means that if they fall within the first and last sequence numbers of the target product, then those files are expected to be found in the RTM media instead of in the patch media. Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Monday, September 10, 2007 10:23 AM To: Windows Installer Support (MS Internal); wix-users@lists.sourceforge.net; Windows Installer XML; Rob Mensching; [EMAIL PROTECTED] Subject: RE: error 1334 due to file sequencing. +wix-dev mailing list and setupsup Note that file sequencing was changed in SP1 (after RTM was released) for few files in one of the merge modules used. I fixed it so that the merge modules file sequencing is now exactly the same as before (though some merge modules have now additional files too at the end of sequencing in File Table). After integrating the merge module into MSI the sequencing seems to have changed. Why is this happening and how do I ensure the file sequencing is preserved on merging the modules. Thanks and Regards, Sandip From: Sandip Shahane Sent: Friday, September 07, 2007 4:58 PM To: 'wix-users@lists.sourceforge.net'; Windows Installer XML; Rob Mensching Subject: RE: error 1334 due to file sequencing. Hi, Is there any document on how wix creates the MSI generally and File table in particular. I am interested in understanding how the files are ordered in the File table by the Wix. I want to troubleshoot this issue I am facing (seems like it is similar to http://sourceforge.net/mailarchive/message.php?msg_id=E1FZMWn-0007MY-CR%40sc8-sf-web5.sourceforge.net ). We have RTM MSI built using Wix It is composed of few merge modules. Now we have built a SP of the same RTM with few new files and few file updates in the existing merge modules. Also we have added a merge module to the MSI. Now after reinstalling a feature we get error 1334 (file not found in cab). I noticed the file sequencing was changed so I went and did the changes to add PatchGroup attribute to all new files in the respective merge modules (with incremental PatchGroup value for each new file). But still files are not in correct order. Files ordering is changed even before I come across a new file in the File table. On comparing every merge module I observed existing files are in same order with additional files at the end of each merge modules. Also during SP1 we have changed the Package InstallerVersion='300' from InstallerVersion='200'. I have created patch using msimsp
[WiX-users] error 1334 due to file sequencing.
I noticed that file sequencing was changed for few files in one of the merge modules used. I fixed it so that both the merge modules file sequencing is now exactly the same. But after integrating the merge module into MSI the sequencing seems to have changed. Why is this happening and how do I ensure the file sequencing is preserved on merging the modules. From: Hemchander Sannidhanam Sent: Thursday, September 06, 2007 1:15 PM To: Sandip Shahane; Windows Installer Support (MS Internal) Subject: RE: file sequencing... Unfortunately, there is no ICE to validate an MSP. To just give you an idea of the reason behind the 1334 error: 1. Windows Installer looks at an MSI (with all patches applied to its in-memory view of the RTM MSI) and goes through the files in the File table in a sequence sorted by the Sequence column of the File table. 2. For each of these files that needs to be updated or installed as part of this transaction, it creates a FileCopy (or PatchApply) opcode and queues it up in the installation script 3. When the Windows Installer's executor looks at the FileCopy (or PatchApply) opcode and realizes that the file is compressed, it goes looking inside the cab related to this file. 4. We extract files from the cab sequentially (not random access). This means if the files listed in the File table and the ones inside the cab are not in the same order, you will see this 1334 error. If you changed the File sequence numbers between your RTM and SP1, then the in-memory view of the MSI will have a File table whose sequence numbers might not match with that of the cab. This is the primary reason for the 1334 error while applying a patch. Hem. From: Sandip Shahane Sent: Tuesday, September 04, 2007 3:49 PM To: Windows Installer Support (MS Internal) Subject: file sequencing... Hi, How do we make sure the newly added files in an existing merge modules does not break MSI rule of file sequencing? We have several merge modules in our product setup (built using Wix) and most of them have new files added (we added PatchGroup attribute to newly added files and also added them as a separate components at the end of the component element list under Directory element). Now after upgrading the existing RTM product to this SP and doing reinstall of a feature it gives error 1334 (file not found in the cab). My understanding is this is due to file sequencing conflict (the orca shows few files in File table as changed only for Sequence column, rest all remaining same). I am not sure what else might be missing or need to do to make sure the file sequencing is correct. Is there any ICE .cub that I can use to validate the package against file ordering? Thanks in advance, Sandip - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error 1334 due to file sequencing.
Hi, Is there any document on how wix creates the MSI generally and File table in particular. I am interested in understanding how the files are ordered in the File table by the Wix. I want to troubleshoot this issue I am facing (seems like it is similar to http://sourceforge.net/mailarchive/message.php?msg_id=E1FZMWn-0007MY-CR%40sc8-sf-web5.sourceforge.net ). We have RTM MSI built using Wix It is composed of few merge modules. Now we have built a SP of the same RTM with few new files and few file updates in the existing merge modules. Also we have added a merge module to the MSI. Now after reinstalling a feature we get error 1334 (file not found in cab). I noticed the file sequencing was changed so I went and did the changes to add PatchGroup attribute to all new files in the respective merge modules (with incremental PatchGroup value for each new file). But still files are not in correct order. Files ordering is changed even before I come across a new file in the File table. On comparing every merge module I observed existing files are in same order with additional files at the end of each merge modules. Also during SP1 we have changed the Package InstallerVersion='300' from InstallerVersion='200'. I have created patch using msimsp and provided FileSequencStart as sufficiently large number. Any guidance / pointers will be greatly appreciated as we are blocked here. Thanks and Regards, Sandip From: Sandip Shahane Sent: Friday, September 07, 2007 11:13 AM To: wix-users@lists.sourceforge.net; Windows Installer XML Subject: error 1334 due to file sequencing. I noticed that file sequencing was changed for few files in one of the merge modules used. I fixed it so that both the merge modules file sequencing is now exactly the same. But after integrating the merge module into MSI the sequencing seems to have changed. Why is this happening and how do I ensure the file sequencing is preserved on merging the modules. From: Hemchander Sannidhanam Sent: Thursday, September 06, 2007 1:15 PM To: Sandip Shahane; Windows Installer Support (MS Internal) Subject: RE: file sequencing... Unfortunately, there is no ICE to validate an MSP. To just give you an idea of the reason behind the 1334 error: 1. Windows Installer looks at an MSI (with all patches applied to its in-memory view of the RTM MSI) and goes through the files in the File table in a sequence sorted by the Sequence column of the File table. 2. For each of these files that needs to be updated or installed as part of this transaction, it creates a FileCopy (or PatchApply) opcode and queues it up in the installation script 3. When the Windows Installer's executor looks at the FileCopy (or PatchApply) opcode and realizes that the file is compressed, it goes looking inside the cab related to this file. 4. We extract files from the cab sequentially (not random access). This means if the files listed in the File table and the ones inside the cab are not in the same order, you will see this 1334 error. If you changed the File sequence numbers between your RTM and SP1, then the in-memory view of the MSI will have a File table whose sequence numbers might not match with that of the cab. This is the primary reason for the 1334 error while applying a patch. Hem. From: Sandip Shahane Sent: Tuesday, September 04, 2007 3:49 PM To: Windows Installer Support (MS Internal) Subject: file sequencing... Hi, How do we make sure the newly added files in an existing merge modules does not break MSI rule of file sequencing? We have several merge modules in our product setup (built using Wix) and most of them have new files added (we added PatchGroup attribute to newly added files and also added them as a separate components at the end of the component element list under Directory element). Now after upgrading the existing RTM product to this SP and doing reinstall of a feature it gives error 1334 (file not found in the cab). My understanding is this is due to file sequencing conflict (the orca shows few files in File table as changed only for Sequence column, rest all remaining same). I am not sure what else might be missing or need to do to make sure the file sequencing is correct. Is there any ICE .cub that I can use to validate the package against file ordering? Thanks in advance, Sandip - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error 1334 on installing a patch.
We have added few files in the existing components and also added new components. Now, on taking a delta on the newly built MSI with the RTM MSI the originally existing files are seen out of order. There are around 200+ such files. Here are the packages and the msp file for quick reference. RTM MSI: \\smx.net\builds\MOMV3\en\5000\retail\x86\SelectCdImage\server\i386\MOM.msifile:///\\smx.net\builds\MOMV3\en\5000\retail\x86\SelectCdImage\server\i386\MOM.msi Updated MSI: \\smx.net\builds\MOMv3.SP1\en\6027\retail\x86\SelectCdImage\server\i386\MOM.msifile:///\\smx.net\builds\MOMv3.SP1\en\6027\retail\x86\SelectCdImage\server\i386\MOM.msi Patch location: \\smx.net\builds\MOMv3.SP1\en\6027\retail\x86\SP1UpdateImage\MOM2007SP1.mspfile:///\\smx.net\builds\MOMv3.SP1\en\6027\retail\x86\SP1UpdateImage\MOM2007SP1.msp Thanks and Regards, Sandip From: Rob Mensching Sent: Sunday, June 17, 2007 9:48 AM To: Sandip Shahane; wix-users@lists.sourceforge.net Subject: RE: error 1334 on installing a patch. The PatchGroup element is used to ensure that new files get added to the end of the sequence. That has been able to solve all the sequencing problems people have brought up in the past so can you be more specific about what files you're finding are out of sequence? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandip Shahane Sent: Wednesday, June 13, 2007 3:47 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] error 1334 on installing a patch. So, how do I control the file sequencing? PatchGroup attribute seems like something for files that are newly added by the patch (correct me if wrong). So here is the scenario and problem I am facing: There is an original MSI with a File table snap shot for couple of files as below and an updated package that has some new files, some existing files and some updated files. Also in updated MSI File table the file sequence is completely different than the RTM one. Probably because of this I am getting, error 1334 for the below files while installing a patch. Now, since I am using WIX, I want to know is there any way I can make sure the file sequence remains same for the files that are not updated in the new package? Also is there a way to know how and why the sequence might have changed in the first place? Any help will be greatly appreciated, Thanks and Regards, Sandip From: Heath Stewart Sent: Wednesday, June 13, 2007 2:55 PM To: Sandip Shahane; Carolyn Napier; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. WiX questions need to go to wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net. See http://wix. I will say you should take a look at the wix.chm file for the File element's PatchGroup attribute. Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 13, 2007 1:18 PM To: Carolyn Napier; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. I am not sure how to actually control the file sequencing using WIX. Could you tell what do I need to do to preserve the file sequencing so that the existing files keep same sequence number and new ones are added at the end of the table in updated package. Thanks and Regards, Sandip From: Carolyn Napier Sent: Wednesday, June 13, 2007 11:25 AM To: Sandip Shahane; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. File sequence numbers should stay the same. WiX authoring has the ability to help enforce this. Note that the sequence number is especially important when dealing with cabinets. The sequence number identifies the order of the files in the cabinets. According to RTM authoring, Sdk.diagrams.dll comes before Sdk.dll in the cabinet. However, by your updated MSI authoring, you have now made Sdk.Diagrams come after Sdk.dll in the cabinet. With the patch applied, the file won't be found in the cabinet. In particular, Sdk.Diagrams won't be found because it will have already been bypassed in the seek for Sdk.dll. In short, sequence numbers should not change in patches unless the file is being updated via a full-file update (in which case, the attributes column also changes). From: Sandip Shahane [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 10:28 AM To: Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: error 1334 on installing a patch. Hi, I have created a patch for MOM V3 to SP1 upgrade and while running the update it gives error 1334 The file cannot be installed because the file cannot be found in the cabinet. I applied the patch using orca to notice few things. The file in question had no changes in the File table other than the sequence number (there were number of such files.). Some search about this issue points me that this has something to do
Re: [WiX-users] error 1334 on installing a patch.
Thanks, I will reorganize the new files as suggested, and also add the PatchGroup attribute to the new File elements. From: Rob Mensching Sent: Monday, June 18, 2007 12:55 PM To: Sandip Shahane; wix-users@lists.sourceforge.net Subject: RE: error 1334 on installing a patch. You can't add files to existing Components. That breaks the Component Rules. For the new Components you added, did you mark their Files with the PatchGroup element? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sandip Shahane Sent: Monday, June 18, 2007 12:48 PM To: Rob Mensching; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] error 1334 on installing a patch. We have added few files in the existing components and also added new components. Now, on taking a delta on the newly built MSI with the RTM MSI the originally existing files are seen out of order. There are around 200+ such files. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] error 1334 on installing a patch.
So, how do I control the file sequencing? PatchGroup attribute seems like something for files that are newly added by the patch (correct me if wrong). So here is the scenario and problem I am facing: There is an original MSI with a File table snap shot for couple of files as below and an updated package that has some new files, some existing files and some updated files. Also in updated MSI File table the file sequence is completely different than the RTM one. Probably because of this I am getting, error 1334 for the below files while installing a patch. Now, since I am using WIX, I want to know is there any way I can make sure the file sequence remains same for the files that are not updated in the new package? Also is there a way to know how and why the sequence might have changed in the first place? Any help will be greatly appreciated, Thanks and Regards, Sandip From: Heath Stewart Sent: Wednesday, June 13, 2007 2:55 PM To: Sandip Shahane; Carolyn Napier; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. WiX questions need to go to wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net. See http://wix. I will say you should take a look at the wix.chm file for the File element's PatchGroup attribute. Heath Stewart Technical Lead Deployment Technologies Group, Microsoft http://blogs.msdn.com/heaths From: Sandip Shahane Sent: Wednesday, June 13, 2007 1:18 PM To: Carolyn Napier; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. I am not sure how to actually control the file sequencing using WIX. Could you tell what do I need to do to preserve the file sequencing so that the existing files keep same sequence number and new ones are added at the end of the table in updated package. Thanks and Regards, Sandip From: Carolyn Napier Sent: Wednesday, June 13, 2007 11:25 AM To: Sandip Shahane; Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: RE: error 1334 on installing a patch. File sequence numbers should stay the same. WiX authoring has the ability to help enforce this. Note that the sequence number is especially important when dealing with cabinets. The sequence number identifies the order of the files in the cabinets. According to RTM authoring, Sdk.diagrams.dll comes before Sdk.dll in the cabinet. However, by your updated MSI authoring, you have now made Sdk.Diagrams come after Sdk.dll in the cabinet. With the patch applied, the file won't be found in the cabinet. In particular, Sdk.Diagrams won't be found because it will have already been bypassed in the seek for Sdk.dll. In short, sequence numbers should not change in patches unless the file is being updated via a full-file update (in which case, the attributes column also changes). From: Sandip Shahane [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 13, 2007 10:28 AM To: Windows Installer Support (MS Internal) Cc: Aaron Gaskill Subject: error 1334 on installing a patch. Hi, I have created a patch for MOM V3 to SP1 upgrade and while running the update it gives error 1334 The file cannot be installed because the file cannot be found in the cabinet. I applied the patch using orca to notice few things. The file in question had no changes in the File table other than the sequence number (there were number of such files.). Some search about this issue points me that this has something to do with file sequence numbers. here is how the File tables of two MSIs and MSP looks like: Original MSI: F_Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll.1349CC4A_5003_4833_A142_36725FE46FEA C_Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll.1349CC4A_5003_4833_A142_36725FE46FEA DSLDiag.dll|Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll 822136 8.1.50727.42 0 0 136 F_Microsoft.VisualStudio.Modeling.Sdk.dll.1349CC4A_5003_4833_A142_36725FE46FEA C_Microsoft.VisualStudio.Modeling.Sdk.dll.1349CC4A_5003_4833_A142_36725FE46FEA DSLSDK.dll|Microsoft.VisualStudio.Modeling.Sdk.dll 416632 8.1.50727.42 0 0 138 Updated MSI: F_Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll.1349CC4A_5003_4833_A142_36725FE46FEA C_1 DSLDiag.dll|Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll 822136 8.1.50727.42 0 0 108 F_Microsoft.VisualStudio.Modeling.Sdk.dll.1349CC4A_5003_4833_A142_36725FE46FEA C_Microsoft.VisualStudio.Modeling.Sdk.dll.1349CC4A_5003_4833_A142_36725FE46FEA DSLSDK.dll|Microsoft.VisualStudio.Modeling.Sdk.dll 416632 8.1.50727.42 0 0 106 MSP: F_Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll.1349CC4A_5003_4833_A142_36725FE46FEA C_Microsoft.VisualStudio.Modeling.Sdk.Diagrams.dll
