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 and include 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 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. 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