|
inline From: Wilson, Brad
[mailto:[EMAIL PROTECTED] 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 or AppSearch 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" ?> 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 mismatching problem? [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 aren’t 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 wasn’t
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] 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. It’s not necessary to have this
authoring:
<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, I’d suggest omitting the
Fragment identifiers to save unnecessary effort. - Property/@ComplianceCheck is not necessary if the value is
“no” since it’s 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] 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'?> <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"> 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_*.wixlib file 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] I see the problem now. Since the
AppSearch action is a standard action – the wix toolset defines the
overridable sequencing for the action. You can’t specify
Overridable=”yes” because its already been declared. You can
override the standard sequencing already though, so setting the attribute
shouldn’t 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 it’s 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] 3.0.1828.0 (it's in the subject of the
email). From: Derek
Cicerone [mailto:[EMAIL PROTECTED] What version of candle/WiX are you using? From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Brad I'm trying to use the overridable attribute in some WixLibs
that i've created but when trying to do so, I am receiving the following error
at candle time: candle.exe -nologo -w3 -v0
-dReleaseBuild=Yes ..\ca_ICServerCheck.wxs -ext
"ININ.WiXExtensions.I3WiXExtensions, ININ.WiXExtensions" ..\ca_ICServerCheck.wxs(12) : error
CNDL0004 : The AppSearch element contains an unexpected attribute
'Overridable'. I'm also receiving the same error when using the attribute
with the LaunchConditions element (i'm assuming that it's broken for all
standard actions). Is this a known issue? Brad Wilson | Developer |
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
