My build is failing due to the following condition:
..wxs(138) : error LGHT0204 : ICE03: Bad conditional string; Table:
Condition, Column: Condition, Key(s):
<Feature .....>
<MergeRef Id="Feature" Primary="yes"/>
<Condition Level="0">((PROP1="prop1") OR (PROP2="prop2") OR (PROP3="prop3") OR (PROP4="prop4" AND OR PROP5=""))</Condition>
</Feature>
Is there any mistake in the condition?
Is there any other way to specify this condition?
I have never seen AND OR used in conditions before. Removing OR makes it compile. Hard to tell what you are trying to achieve here without more information.
Related
I'm a novice WiX user, converting over several existing installations from a no longer maintained (.MSI-producing) commercial product.
As part of that I'm restructuring the original feature/component arrangements to take advantage of some of the new options WiX has opened up. One of these is adding Conditions at Feature rather than Component level, and as part of that I've tried specifying a conditional Feature like this (demo/test items throughout):
<Feature Id="Feature1" Title="Test Only" Level="0">
<Component Id="C1" Guid="*" Directory="SomeDir">
<File Id="File1" KeyPath="yes" Checksum="yes" Name="Test file.txt" Source="D:\xxx.dat" />
</Component>
<Condition Level="1"><![CDATA[INSTALLTYPE <> 1]]></Condition>
</Feature>
Where INSTALLTYPE is a Property defined at <Product> level and subsequently set to 0, 1 or 2 by the user via a RadioButtonGroup in the UI sequence.
Summarising what I've found after a day or so of trying different options and head-scratching:
With an initial Level=0, set to 1 by the condition (as in the sample above), the Feature is never installed.
With an initial Level=1, set to 0 by the condition, the Feature is installed when the condition is satisfied as long as an = test is used in the condition. If a INSTALLTYPE <> 1 is used, or Not (INSTALLTYPE = 1), the feature is never installed.
If a pre-defined Property (such as INSTALLLEVEL) is used in the test rather than my INSTALLTYPE, everything works correctly/as expected.
If equivalent tests are applied at Component, rather than Feature, level, everything works as expected for all Propertys and test operators.
Something seems to be going wrong with INSTALLTYPE but I can't for the life of me work out what. I've tried firing a VBScript custom action (MsgBox("INSTALLTYPE=" & Session.Property("INSTALLTYPE"))) in the Execute sequence to check the value of the Property, and as far as I can see this does display the value I'd expect it to have from the UI setting.
In principle I could get Features installing the way I want using the subset of settings I've found to work (e.g. INSTALLTYPE = 0 OR INSTALLTYPE = 2 rather than INSTALLTYPE <> 1), but my bafflement over apparently simple things not behaving as expected suggests I'm missing something fundamental...so I'm wary of just shrugging and applying workarounds.
If anyone has any thoughts on what I might be doing wrong with the items above, I'd be very happy to hear them!
I have the following piece of code in my wxs file for DB.
<Binary Id="binCreateTbl" SourceFile="CREATE_TABLE.sql" />
<sql:SqlScript BinaryKey="binCreateTbl" Id="script_CreateTbl" ExecuteOnInstall="yes" Sequence="2"/>
<sql:SqlScript BinaryKey="binCreateTbl" Id="script_CreateTbl1" RollbackOnUninstall="yes" Sequence="1" />
The Create_Table.sql just contains a create table statement with just two simple columns namely ID and Name. When installing the MSI, the table is getting created in the DB, but while uninstalling, the table is not getting removed / dropped. Any idea how to achieve this? I know that including the following piece of code instead of the line with RollbackOnUninstall=yes, then it works. But I want to avoid it. Please help.
<Binary Id="binDropTbl" SourceFile="DROP_TABLE.sql" />
<sql:SqlScript BinaryKey="binDropTbl" Id="script_DropTbl" ExecuteOnUninstall="yes" />
Looks like this is not possible. Since MSI has no way of knowing what is written inside of the sql file, it cannot be rolled back simply using RollbackOnUninstall=yes. There has to be a separate script which will include the code to delete / remove the table during uninstall and it has to be called using ExecuteOnUninstall=yes.
When I add a Condition within a Feature to assure that IIS is installed, it is working as expected (it searches installed IIS, when feature is selected. No check, when feature is not selected):
<Feature Id="feat.WebApplication"
Title="Web Application"
Level="1"
ConfigurableDirectory="DIR.WEBAPP">
<Condition Level="0">
<![CDATA[Installed OR (IISMAJORVERSION AND IISMAJORVERSION >= "#7")]]>
</Condition>
<!-- ... -->
</Feature>
But - as documented in Condition Element - it is not allowed to have a message within the condition. So the installation silently fails, whereas it shows a message when the condition is placed directly in the Product node.
How can I show a message also for conditions within features?
As I understand the Condition node, after reading about the Level attribute of the Feature Element,
Sets the install level of this feature. A value of 0 will disable the feature. Processing the Condition Table can modify the level value (this is set via the Condition child element). The default value is "1".
by using Condition within feature you get the ability to disable or enable features depending on its own value for Level, because you can override it if the condition matches with the value of the Level attribute of the condition.
So the best would be to add some text about the precondition to the feature Description.
I have a requirement like this, Under the root tag 'Features' multiple feature elements are present.I need to remove duplicates. I have loaded its corresponding xsd in both source and target. But was not sure how to remove duplicates. My xml is a complex one, but to understand, I made here as simple.
Source ( input xml)
<features>
......(other fields)...
<Datas>
<feature> 1</feature>
<feature> 2 </feature>
<feature> 1 </feature>
<feature> 3 </feature>
<feature> 3 </feature>
</Datas>
</features>
Target ( output xml)
<features>
....(other fields)....
<ItemDetails>
<feature> 1</feature>
<feature> 2 </feature>
<feature> 3 </feature>
</ItemDetails>
I was thinking, something need to do in For each element in DataMapper. But not sure how can be done or may be it is wrong
Please let me know if any short cut, crispy way to remove the duplicates. It will reduce my time in large.
Mule version: 3.5.1
Thanks in advance.
This cannot be accomplished with DataMapper, you need an ulterior XSLT transformer to remove duplicates, see the following stackoverflow question.
I have resolved the problem in this way.
First I used Datamapper. It will gives as response but with duplicates. Finally I used Simple XSLT as described in this link Removing duplicate elements with XSLT( It removes duplicates alone) and make copy of remaining transformed field as such ( I used XSLT v1 in the link)
Hope It might helps for those facing the problem like me.
I would like to install a feature according to the brand.
So in my brand.wxi I defined:
<?define brand.FeatureLevel = 1 ?>
And in my wxs I wrote:
<Feature Id="FF" Title="FF" Level="$(var.brand.FeatureLevel)">
<ComponentRef Id="..." />
<ComponentRef Id="..." />
</Feature>
This definition works fine (wheather I've placed 0 or 1 as FeatureLevel).
My only problem is a warning I get at compilation time:
The 'Level' attribute is invalid - The value '$(var.brand.FeatureLevel)' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:integer' - The string '$(var.brand.FeatureLevel)' is not a valid Integer value.
Is there a way to fix this warning?
Can I define integer variable? I couldn't find a way...
You can safely ignore this warning. It just points your attention that this preprocessor variable must evaluate to integer. Otherwise, if you modify brand.FeatureLevel to a letter in the sample above, it will throw an error and simply won't compile.