Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
is there any plan to have a -cultures cmd-line option for lit.exe? The idea here is that we'd like to have a complete dialog set in a wix library that includes all available dialogs and all languages for those dialogs. Then when we need a specific dialog sequence we create a new wixlib andinclude that dialog set, specify a culture, and define our sequence using DialogRef and Publish elements. Then include that sequence in the install wxs file using the UIRef element. And in case I've forgotten to say this, thanks for all of your help on this stuff Derek. You've been a huge help. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 7:00 PMTo: Wilson, Brad; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.netSubject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. inline From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:57 PMTo: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.netSubject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Thanks for the suggestions on cleaning up my wxs file. I try to be efficiently lazy so that certainly helps. I added the InstallUISequence stuff when I first started working on this because I wasn't seeing any entries in the LanuchConditions orAppSearch tables when including the wixlib that clearly had entries specified. [DerekC] There is no LaunchConditions table only a LaunchCondition table. Elements under the InstallUISequence element create actions in the InstallUISequence, not rows in any other table. So I just took those elements out and rebuilt the wixlib. Here is the output from that: ?xml version="1.0" encoding="utf-8" ? wixLibrary version="3.0.1808.0" xmlns="http://schemas.microsoft.com/wix/2003/11/libraries" section type="fragment" xmlns="http://schemas.microsoft.com/wix/2003/04/objects" table name="AppSearch" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*9" fieldICSERVERSITENAME/field fieldICServerCheck/field /tuple /table table name="LaunchCondition" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*7" fieldICSERVERSITENAME/field fieldThis application can not be installed on an IC Server. The install will now exit./field /tuple /table table name="Property" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*9" fieldICSERVERSITENAME/field field / field0/field field0/field field0/field /tuple /table table name="RegLocator" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*10" fieldICServerCheck/field field2/field fieldSOFTWARE\Interactive Intelligence\EIC\Directory Services\Root/field fieldSITE/field field2/field /tuple /table /section/wixLibrary When I build the wrapper install and include the wixlib, i'm not seeing those entries in the specified tables and the actions are not being scheduled. One thing I did notice is that the version of the WixLibrary says 3.0.1808.0. When I view the versions of the files i'm using to build everything they all say 3.0.1828.0. Is it possible that the wix source wasn't updated to insert the 1828 version? Or do I have a version mismatchingproblem? [DerekC] The wix library version is actually hard-coded. It does not need to match the version of the wix toolset you are using. In fact, it hardly ever does. The version in the wixlib files is updated when the schema of the wixlib file format is modified (as it was recently). It could be months before its updated again (or never). Assuming that version 1808 in the wixlib file is ok, and that I'm including the wixlib appropriately when calling light.exe, what else could cause the entries from the above wixlib file to not be created in the msi file? [DerekC] You likely arent referencing anything from the Fragment. Create a PropertyRef Id=ICSERVERSITENAME / element in your main wix authoring. This will reference the Property in the Fragment and pull it into the product (or module). This is one of the main concepts of WiX creating references to build up an installation from lots of little pieces. As a test I just removed the wixlib from being included in the wrapper install and inserted the Condition and Property elements directly in the wxs file for the install. When built, the install now has the appropriate tables and actions. [DerekC] That makes sense because the authoring wasnt being referenced follow the instructions above and it should work. So this is either some problem where i'm by mistake not including the wixlib or those elements in a wixlib that is included in an install wrapper is not resulting in the tables and actions being put in the msi. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 2:28 PMTo: Wilson, Brad; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.netSubject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Adding wix-users to
Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
Adding wix-users to this topic I just noticed it was sent to wix-devs. Please only use wix-devs for discussions of code and other internals of the WiX toolset, all discussion about using the toolset should go to wix-users. Its not necessary to have this authoring: InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence Those actions are all included automatically when they are needed: - Condition should add the LaunchConditions action at 100. - RegistrySearch should add the AppSearch action at 50. - FindRelatedProducts is used by the Upgrade table, so its actually not needed in the below authoring. You can schedule your custom actions using the Before/After attributes, so there would be no need for using the AppSearch, LaunchCondition, etc elements for that either. Other unnecessary authoring: - Fragment/@Id is only needed in extremely rare circumstances. Since FragmentRef is no longer supported, Id suggest omitting the Fragment identifiers to save unnecessary effort. - Property/@ComplianceCheck is not necessary if the value is no since its the default. - Specifying a Value for a property set by a RegistrySearch is also usually not necessary since you can more easily check for the existence of a property versus a specific value. It looks like relying upon the built-in capabilities of WiX a bit more will save authoring effort as well as enable your scenarios to work (but we should still open a bug against the Overridable attribute not working on standard action elements). Thanks, Derek From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 11:10 AM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. The reason we wanted this functionality is because we are trying to create wixlibs that are very specific. So for example, I've got a wixlib and all it does is check to see if the target machine has some other application installed on it. So here is that wxs file: ?xml version='1.0' encoding='UTF-8'? Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' xmlns:inin='http://www.inin.com/i3WixExtensions' Fragment Id=ca_ICServerCheck Condition Message=This application can not be installed on an IC Server. The install will now exit.![CDATA[ICSERVERSITENAME ]]/Condition Property Id=ICSERVERSITENAME Value=0 ComplianceCheck=no RegistrySearch Id=ICServerCheck Root=HKLM Key=SOFTWARE\Interactive Intelligence\EIC\Directory Services\Root Name=SITE Type=raw / /Property InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence /Fragment /Wix So this wix file is built as a wixlib.Then for any given install, all it as to do is include the ca_ICServerCheck.wixlib file and it's included in the install. And now when any other install needs that launch condition, it's done exactly the same way. And if it changes, it changes for every install. That being said, we will have lots of custom actions that will do the same sort of thing. So we can't include the AppSearch and LaunchConditions elements in every single ca_*.wixlibfile because when the wrapper install is built, it sees multiple of the same element and fails. We were hoping that the Overridable attribute would allow for this functionality. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:20 PM To: Wilson, Brad; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. I see the problem now. Since the AppSearch action is a standard action the wix toolset defines the overridable sequencing for the action. You cant specify Overridable=yes because its already been declared. You can override the standard sequencing already though, so setting the attribute shouldnt be necessary. Unlike custom actions, you should keep the sequencing for standard actions, well, standard across all products that you ship. It should not be tweaked for some products and not others. Why are you attempting to modify the sequencing of AppSearch and LaunchConditions? They are already sequenced so that AppSearch occurs before LaunchConditions. Please open a bug against this in the least its a documentation issue because Overridable should not be supported on the AppSearch element. Please assign the bug to me. Thanks, Derek From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 10:07 AM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. 3.0.1828.0 (it's in the subject of the email). From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:03 PM To: Wilson, Brad;
Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
Thanks for the suggestions on cleaning up my wxs file. I try to be efficiently lazy so that certainly helps. I added the InstallUISequence stuff when I first started working on this because I wasn't seeing any entries in the LanuchConditions orAppSearch tables when including the wixlib that clearly had entries specified. So I just took those elements out and rebuilt the wixlib. Here is the output from that: ?xml version="1.0" encoding="utf-8" ? wixLibrary version="3.0.1808.0" xmlns="http://schemas.microsoft.com/wix/2003/11/libraries" section type="fragment" xmlns="http://schemas.microsoft.com/wix/2003/04/objects" table name="AppSearch" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*9" fieldICSERVERSITENAME/field fieldICServerCheck/field /tuple /table table name="LaunchCondition" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*7" fieldICSERVERSITENAME/field fieldThis application can not be installed on an IC Server. The install will now exit./field /tuple /table table name="Property" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*9" fieldICSERVERSITENAME/field field / field0/field field0/field field0/field /tuple /table table name="RegLocator" tuple sourceLineNumber="..\ca_ICServerCheck.wxs*10" fieldICServerCheck/field field2/field fieldSOFTWARE\Interactive Intelligence\EIC\Directory Services\Root/field fieldSITE/field field2/field /tuple /table /section/wixLibrary When I build the wrapper install and include the wixlib, i'm not seeing those entries in the specified tables and the actions are not being scheduled. One thing I did notice is that the version of the WixLibrary says 3.0.1808.0. When I view the versions of the files i'm using to build everything they all say 3.0.1828.0. Is it possible that the wix source wasn't updated to insert the 1828 version? Or do I have a version mismatchingproblem? Assuming that version 1808 in the wixlib file is ok, and that I'm including the wixlib appropriately when calling light.exe, what else could cause the entries from the above wixlib file to not be created in the msi file? As a test I just removed the wixlib from being included in the wrapper install and inserted the Condition and Property elements directly in the wxs file for the install. When built, the install now has the appropriate tables and actions. So this is either some problem where i'm by mistake not including the wixlib or those elements in a wixlib that is included in an install wrapper is not resulting in the tables and actions being put in the msi. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 2:28 PMTo: Wilson, Brad; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.netSubject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Adding wix-users to this topic I just noticed it was sent to wix-devs. Please only use wix-devs for discussions of code and other internals of the WiX toolset, all discussion about using the toolset should go to wix-users. Its not necessary to have this authoring: InstallUISequence AppSearch Sequence="50" Overridable="yes" / LaunchConditions Sequence="51" Overridable="yes"/ FindRelatedProducts Sequence="60" / /InstallUISequence Those actions are all included automatically when they are needed: - Condition should add the LaunchConditions action at 100. - RegistrySearch should add the AppSearch action at 50. - FindRelatedProducts is used by the Upgrade table, so its actually not needed in the below authoring. You can schedule your custom actions using the Before/After attributes, so there would be no need for using the AppSearch, LaunchCondition, etc elements for that either. Other unnecessary authoring: - Fragment/@Id is only needed in extremely rare circumstances. Since FragmentRef is no longer supported, Id suggest omitting the Fragment identifiers to save unnecessary effort. - Property/@ComplianceCheck is not necessary if the value is no since its the default. - Specifying a Value for a property set by a RegistrySearch is also usually not necessary since you can more easily check for the existence of a property versus a specific value. It looks like relying upon the built-in capabilities of WiX a bit more will save authoring effort as well as enable your scenarios to work (but we should still open a bug against the Overridable attribute not working on standard action elements). Thanks, Derek From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 11:10 AMTo: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. The reason we wanted this functionality is because we are trying to create wixlibs that are very specific. So for example, I've got a wixlib and all it does is check to see if the target machine has some other application installed on it. So here is that wxs file:
Re: [WiX-users] [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak.
inline From: Wilson, Brad [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 1:57 PM To: [EMAIL PROTECTED]; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Thanks for the suggestions on cleaning up my wxs file. I try to be efficiently lazy so that certainly helps. I added the InstallUISequence stuff when I first started working on this because I wasn't seeing any entries in the LanuchConditions orAppSearch tables when including the wixlib that clearly had entries specified. [DerekC] There is no LaunchConditions table only a LaunchCondition table. Elements under the InstallUISequence element create actions in the InstallUISequence, not rows in any other table. So I just took those elements out and rebuilt the wixlib. Here is the output from that: ?xml version=1.0 encoding=utf-8 ? wixLibrary version=3.0.1808.0 xmlns=http://schemas.microsoft.com/wix/2003/11/libraries section type=fragment xmlns=http://schemas.microsoft.com/wix/2003/04/objects table name=AppSearch tuple sourceLineNumber=..\ca_ICServerCheck.wxs*9 fieldICSERVERSITENAME/field fieldICServerCheck/field /tuple /table table name=LaunchCondition tuple sourceLineNumber=..\ca_ICServerCheck.wxs*7 fieldICSERVERSITENAME/field fieldThis application can not be installed on an IC Server. The install will now exit./field /tuple /table table name=Property tuple sourceLineNumber=..\ca_ICServerCheck.wxs*9 fieldICSERVERSITENAME/field field / field0/field field0/field field0/field /tuple /table table name=RegLocator tuple sourceLineNumber=..\ca_ICServerCheck.wxs*10 fieldICServerCheck/field field2/field fieldSOFTWARE\Interactive Intelligence\EIC\Directory Services\Root/field fieldSITE/field field2/field /tuple /table /section /wixLibrary When I build the wrapper install and include the wixlib, i'm not seeing those entries in the specified tables and the actions are not being scheduled. One thing I did notice is that the version of the WixLibrary says 3.0.1808.0. When I view the versions of the files i'm using to build everything they all say 3.0.1828.0. Is it possible that the wix source wasn't updated to insert the 1828 version? Or do I have a version mismatchingproblem? [DerekC] The wix library version is actually hard-coded. It does not need to match the version of the wix toolset you are using. In fact, it hardly ever does. The version in the wixlib files is updated when the schema of the wixlib file format is modified (as it was recently). It could be months before its updated again (or never). Assuming that version 1808 in the wixlib file is ok, and that I'm including the wixlib appropriately when calling light.exe, what else could cause the entries from the above wixlib file to not be created in the msi file? [DerekC] You likely arent referencing anything from the Fragment. Create a PropertyRef Id=ICSERVERSITENAME / element in your main wix authoring. This will reference the Property in the Fragment and pull it into the product (or module). This is one of the main concepts of WiX creating references to build up an installation from lots of little pieces. As a test I just removed the wixlib from being included in the wrapper install and inserted the Condition and Property elements directly in the wxs file for the install. When built, the install now has the appropriate tables and actions. [DerekC] That makes sense because the authoring wasnt being referenced follow the instructions above and it should work. So this is either some problem where i'm by mistake not including the wixlib or those elements in a wixlib that is included in an install wrapper is not resulting in the tables and actions being put in the msi. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 2:28 PM To: Wilson, Brad; wix-devs@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: RE: [WiX-devs] WiX v3.0.1828.0 Overridable attribute causing buildbreak. Adding wix-users to this topic I just noticed it was sent to wix-devs. Please only use wix-devs for discussions of code and other internals of the WiX toolset, all discussion about using the toolset should go to wix-users. Its not necessary to have this authoring: InstallUISequence AppSearch Sequence=50 Overridable=yes / LaunchConditions Sequence=51 Overridable=yes/ FindRelatedProducts Sequence=60 / /InstallUISequence Those actions are all included automatically when they are needed: - Condition should add the LaunchConditions action at 100. - RegistrySearch should add the AppSearch action at 50. - FindRelatedProducts is used by the Upgrade table, so its actually not needed in the below authoring. You can schedule your custom actions using the Before/After attributes, so there would be no need for using the AppSearch, LaunchCondition, etc
