|
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. 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"> <field>ICSERVERSITENAME</field> <field>ICServerCheck</field> </tuple> </table> <table name="LaunchCondition"> <tuple sourceLineNumber="..\ca_ICServerCheck.wxs*7"> <field>ICSERVERSITENAME</field> <field>This 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"> <field>ICSERVERSITENAME</field> <field /> <field>0</field> <field>0</field> <field>0</field> </tuple> </table> <table name="RegLocator"> <tuple sourceLineNumber="..\ca_ICServerCheck.wxs*10"> <field>ICServerCheck</field> <field>2</field> <field>SOFTWARE\Interactive Intelligence\EIC\Directory Services\Root</field> <field>SITE</field> <field>2</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
mismatching problem?
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 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. 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
