Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
Was probably using wix 3.0.4004.0 back when this thread was sent. -Original Message- From: Heath Stewart [mailto:clubs...@gmail.com] Sent: Friday, April 03, 2009 12:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values What version of WiX v3 are you using. A while back I made a change to support the actual database schema so if your MSIs don't match the schema WiX expects it shouldn't be a problem. Now, if your target and upgrade database schemas different the error is there because Windows Installer will fail to install such a patch and it's really hard to diagnose. Rather than failing with an error message stating something like, The transform is invalid, the database will be garbled within the transform and the failure code could be almost anything depending on what data is garbled and when it's used. Transforms - and by extension patches, since they just contain a bunch of transforms - cannot change the database schemas except to add a new column or a new table. See https://blogs.msdn.com/heaths/archive/2007/09/01/column-types-cannot-be-changed-in-a-patch-or-transform.aspxfor more information. On Sun, Sep 14, 2008 at 1:28 PM, Robert O'Brien robert.obr...@microsoft.com wrote: Thanks that appears to be exactly what my issue was with my adminInstall output. I used orca to reconfigure the feature level settings in my v1.0 msi so I could generate a useable adminInstall of it and configured my in progress v1.1 sources to instead use the following feature install condition logic so its build output will directly support generation of a useable adminInstall. Feature Id=Databases Title=!(loc.Databases) Level=1 Condition Level=0DATABASES=0/Condition versus what I had Feature Id=Databases Title=!(loc.Databases) Level=0 Condition Level=1DATABASES=1/Condition At this point using new wix3 way for patch generation is spitting out the following torch.exe processing command error. If I switch to the old msimsp way for patch generation it doesn't seem to have that same issue. I even tried rebuilding my v1.0 msi output using the same wix framework release as I'm using for my v1.1 work and it didn't make the torch.exe RadioButton error go away. Error 2 The table definition of 'RadioButton' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. D:\tfswf\ws0\RXD_RXG_PTF\RXP Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification Service.msi 0 1 Patch !-- new wix3 way for patch generation -- Patch AllowRemoval=yes Description=!(loc.ProductName) Manufacturer=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) Classification=Update DisplayName=!(loc.ProductName) Media Id=5000 Cabinet=Rtm.cab PatchBaseline Id=Rtm / /Media PatchFamilyRef Id=v11ReleasePatchFamily/ /Patch Fragment PatchFamily Id=v11ReleasePatchFamily Version=1.0.0.0 Supersede=yes ComponentRef Id=Service1 / /PatchFamily /Fragment Patch.wixproj | postBuild event move /y $(TargetDir)en-us\$(TargetName).msi $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp robocopy \\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt $(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt /mir /r:0 if not exist $(ProjectDir)obj\$(Configuration)\v1.1adminInstall md $(ProjectDir)obj\$(Configuration)\v1.1adminInstall rem msiexec.exe /a $(Setup.TargetDir)en-us\$(Setup.TargetFileName) /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == msiexec.exe /a $(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == false msiexec.exe /a $(OutDir)en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe -p -ax $(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries $(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification Service.msi $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.msi -out $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp -out $(TargetDir)en-us\$(TargetName).msp -t Rtm
Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
What version of WiX v3 are you using. A while back I made a change to support the actual database schema so if your MSIs don't match the schema WiX expects it shouldn't be a problem. Now, if your target and upgrade database schemas different the error is there because Windows Installer will fail to install such a patch and it's really hard to diagnose. Rather than failing with an error message stating something like, The transform is invalid, the database will be garbled within the transform and the failure code could be almost anything depending on what data is garbled and when it's used. Transforms - and by extension patches, since they just contain a bunch of transforms - cannot change the database schemas except to add a new column or a new table. See https://blogs.msdn.com/heaths/archive/2007/09/01/column-types-cannot-be-changed-in-a-patch-or-transform.aspxfor more information. On Sun, Sep 14, 2008 at 1:28 PM, Robert O'Brien robert.obr...@microsoft.com wrote: Thanks that appears to be exactly what my issue was with my adminInstall output. I used orca to reconfigure the feature level settings in my v1.0 msi so I could generate a useable adminInstall of it and configured my in progress v1.1 sources to instead use the following feature install condition logic so its build output will directly support generation of a useable adminInstall. Feature Id=Databases Title=!(loc.Databases) Level=1 Condition Level=0DATABASES=0/Condition versus what I had Feature Id=Databases Title=!(loc.Databases) Level=0 Condition Level=1DATABASES=1/Condition At this point using new wix3 way for patch generation is spitting out the following torch.exe processing command error. If I switch to the old msimsp way for patch generation it doesn't seem to have that same issue. I even tried rebuilding my v1.0 msi output using the same wix framework release as I'm using for my v1.1 work and it didn't make the torch.exe RadioButton error go away. Error 2 The table definition of 'RadioButton' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. D:\tfswf\ws0\RXD_RXG_PTF\RXP Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification Service.msi 0 1 Patch !-- new wix3 way for patch generation -- Patch AllowRemoval=yes Description=!(loc.ProductName) Manufacturer=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) Classification=Update DisplayName=!(loc.ProductName) Media Id=5000 Cabinet=Rtm.cab PatchBaseline Id=Rtm / /Media PatchFamilyRef Id=v11ReleasePatchFamily/ /Patch Fragment PatchFamily Id=v11ReleasePatchFamily Version=1.0.0.0 Supersede=yes ComponentRef Id=Service1 / /PatchFamily /Fragment Patch.wixproj | postBuild event move /y $(TargetDir)en-us\$(TargetName).msi $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp robocopy \\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt $(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt /mir /r:0 if not exist $(ProjectDir)obj\$(Configuration)\v1.1adminInstall md $(ProjectDir)obj\$(Configuration)\v1.1adminInstall rem msiexec.exe /a $(Setup.TargetDir)en-us\$(Setup.TargetFileName) /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == msiexec.exe /a $(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == false msiexec.exe /a $(OutDir)en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe -p -ax $(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries $(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification Service.msi $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.msi -out $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp -out $(TargetDir)en-us\$(TargetName).msp -t Rtm $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst cmd /c echo end processing patch post-build event command lines Patch.wixproj | postBuild event !-- old msimsp way for patch generation -- PatchCreation Id=C86050B6-37EC-4BE8-A9D0-A9C61DA42ED6 CleanWorkingFolder=yes OutputPath=!(loc.ProductName).pcp WholeFilesOnly=yes PatchInformation
Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
Thanks that appears to be exactly what my issue was with my adminInstall output. I used orca to reconfigure the feature level settings in my v1.0 msi so I could generate a useable adminInstall of it and configured my in progress v1.1 sources to instead use the following feature install condition logic so its build output will directly support generation of a useable adminInstall. Feature Id=Databases Title=!(loc.Databases) Level=1 Condition Level=0DATABASES=0/Condition versus what I had Feature Id=Databases Title=!(loc.Databases) Level=0 Condition Level=1DATABASES=1/Condition At this point using new wix3 way for patch generation is spitting out the following torch.exe processing command error. If I switch to the old msimsp way for patch generation it doesn't seem to have that same issue. I even tried rebuilding my v1.0 msi output using the same wix framework release as I'm using for my v1.1 work and it didn't make the torch.exe RadioButton error go away. Error 2 The table definition of 'RadioButton' in the target database does not match the table definition in the updated database. A transform requires that the target database schema match the updated database schema. D:\tfswf\ws0\RXD_RXG_PTF\RXP Eventing\Main\Setup\Patch\obj\Debug\v1.0adminInstall\RP Event Notification Service.msi 0 1 Patch !-- new wix3 way for patch generation -- Patch AllowRemoval=yes Description=!(loc.ProductName) Manufacturer=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) Classification=Update DisplayName=!(loc.ProductName) Media Id=5000 Cabinet=Rtm.cab PatchBaseline Id=Rtm / /Media PatchFamilyRef Id=v11ReleasePatchFamily/ /Patch Fragment PatchFamily Id=v11ReleasePatchFamily Version=1.0.0.0 Supersede=yes ComponentRef Id=Service1 / /PatchFamily /Fragment Patch.wixproj | postBuild event move /y $(TargetDir)en-us\$(TargetName).msi $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp robocopy \\rpbuildagent03\builds\RXP Eventing\v1.0adminInstallAlt $(ProjectDir)obj\$(Configuration)\v1.0adminInstallAlt /mir /r:0 if not exist $(ProjectDir)obj\$(Configuration)\v1.1adminInstall md $(ProjectDir)obj\$(Configuration)\v1.1adminInstall rem msiexec.exe /a $(Setup.TargetDir)en-us\$(Setup.TargetFileName) /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == msiexec.exe /a $(SolutionDir)Setup\Setup\bin\$(Configuration)\en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log if $(IsDesktopBuild) == false msiexec.exe /a $(OutDir)en-us\RP Event Notification Service.msi /qn TARGETDIR=$(ProjectDir)obj\$(Configuration)\v1.1adminInstall /l* $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.log $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\torch.exe -p -ax $(ProjectDir)obj\$(Configuration)\extractedAdminInstallBinaries $(ProjectDir)obj\$(Configuration)\v1.0adminInstall\RP Event Notification Service.msi $(ProjectDir)obj\$(Configuration)\v1.1adminInstall\RP Event Notification Service.msi -out $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst $(MSBuildExtensionsPath)\..\Windows Installer XML v3\bin\pyro.exe $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmsp -out $(TargetDir)en-us\$(TargetName).msp -t Rtm $(ProjectDir)obj\$(Configuration)\$(TargetName).wixmst cmd /c echo end processing patch post-build event command lines Patch.wixproj | postBuild event !-- old msimsp way for patch generation -- PatchCreation Id=C86050B6-37EC-4BE8-A9D0-A9C61DA42ED6 CleanWorkingFolder=yes OutputPath=!(loc.ProductName).pcp WholeFilesOnly=yes PatchInformation Description=!(loc.ProductName) Comments=!(loc.ProductName) ShortNames=no Languages=1033 Compressed=yes Manufacturer=!(loc.ProductManufacturer) / PatchMetadata AllowRemoval=yes Description=!(loc.ProductName) ManufacturerName=!(loc.ProductManufacturer) TargetProductName=!(loc.ProductName) MoreInfoURL=!(loc.ProductUrl) Classification=Update DisplayName=!(loc.ProductName) / Family DiskId=5000 MediaSrcProp=v11Patch Name=v11Patch SequenceStart=5000 UpgradeImage Id=v11Upgrade SourceFile=$(var.ProjectDir)obj\$(var.Configuration)\v1.1adminInstall\RP Event Notification Service.msi TargetImage Id=v10Target IgnoreMissingFiles=no Order=2 SourceFile=$(var.ProjectDir)obj\$(var.Configuration)\v1.0adminInstall\RP Event Notification Service.msi / /UpgradeImage /Family PatchSequence
Re: [WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
Robert O'Brien wrote: Any insights on what could be in my pretty typical wix3 sources generated msi's that would be preventing them from successfully creating the expected admininstall output where the contained files are unpacked which is needed for my torch patch installer related command to succeed? If a feature's install level is 0, 'msiexec /a' won't install it. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] using torch.exe -ax to enable use of admin install msi target and update input parameter values
The blog http://blogs.msdn.com/pmarcu/archive/2008/05/30/Patching-something-you-didnt-build-with-WiX-using-WiX-.aspx outlines using torch.exe -ax switch to enable use of admin install msi target and update input parameter values. When I try and do that using the torch command syntax: torch.exe -p -ax obj\Debug\extractedAdminInstallBinaries obj\Debug\v1.0adminInstall\mydeliverable.msi obj\Debug\v1.1adminInstall\ mydeliverable.msi -out obj\Debug\mydeliverable.wixmst I get the error torch.exe: error TRCH0258: The file 'obj\Debug\v1.0adminInstall\mydeliverable\Databases\Database1\SQLScripts\AddSubscribers.sql' cannot be found. If I install either of the target or the update msi's the AddSubscribers.sql file noted is successfully deployed so it would seem it is there. I think this is happening because my admin install folders consist of nothing more than the uncompressed version of the original msi. I'm just using msiexec /a mydeliverable.msi /qn /l*v %temp%\ mydeliverableadminInstall.log to generate my admin installs. Is there some switch or orca or other solution I can used to get the required binary files expanded and included in my admin install output? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
