Feature condition in WiX4. How?

[oleg-shilo]

Condition element is no longer supported in WiX4 schema.
What is the recommended way of porting WiX3 solution impacted by the change?

[robmen]

Feature Level element.

[oleg-shilo]

Great, thank you

[oleg-shilo]

Though it is quite unexpected for an API/schema to define relationships this way.
The Feature documentation specifies Level as an attribute not a child element .

Level (Integer required) : 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".

Ironically the description above it also confirms that Condition is a child element of Feature. Like in WiX3.

And yet Feature Level documentation states that Level is also defined as a child Level element, with Condition and Value attributes.

Seems like the API is not finalized yet. Or it is in fact a defect. As Feature.attribute(Level) conflicts with Feature.elemen(Level).

I did some experiments:

  <Feature Id="feature1_" Title="feature1" Level="3" AllowAbsent="yes">
    <Level Condition="1"/>

Produces error WIX0010: The Level/@Level attribute was not found; it is required.

  <Feature Id="feature1_" Title="feature1" Level="3" AllowAbsent="yes">
    <Level Value="1" Condition="1"/>

Builds OK. Feature column Level has value 3. I would expect it to be an error or at least a warning

  <Feature Id="feature1_" Title="feature1" AllowAbsent="yes">
    <Level Value="1" Condition="1"/>

Builds OK. Feature column Level has value 1

[robmen]

confirms that Condition is a child element of Feature. Like in WiX3.

Typo in the documentation. The fix should be out soon-ish.

error WIX0010: The Level/@Level attribute was not found; it is required.

That is a typo in the error message. The @Level text should be @Value. I opened #7603 and have a fix going now.

Feature column Level has value 3. I would expect it to be an error or at least a warning

The scenario you present here is akin to doing the following in C# code:

var feature = new Feature { Level = 3 }
if (true) 
{
   feature.Level = 1;
}

I don't think that is even flagged as a warning. So while it is totally valid, it is an absolute waste of processor cycles.

[oleg-shilo]

absolute waste of processor cycles.

If you are saying that the problem is the "waste of processor cycle", I am not sure I agree with that.
It's not a WiX problem. It's an API problem. Your clever C# example only gives an additional evidence of that. The C# snippet is equally questionable as the WSX code. Not because the user produced this code but because the API allowed multiple type members to control the very same functionality aspect.

It goes against API good design principles. Regardless of the syntax, C#, Java, WiX etc,.

If it was up to me I would drop int Feature.Level completely and just stick to (int Value, string Condition) Featuer.Level. And if for whatever reason (e.g. legacy needs) both are required then give a warning encouraging user to use only one of them.

I would find soon that the user can specify both. Doesn't matter how silly it is, after all, it was me who allowed that, I designed the API. So I would raise a warning about which value is actually used by the compiler (as candle/wix does in some other cases).

---

BTW thank you for raising that defect on my behalf. And thank you for helping me out with the question. Discovering the Feature-Condition link was close to impossible. Appreciate it.

[robmen]

I'm not sure about that. If I understand your suggestion, I think that design would have the following:

<Feature ... no Level attribute available>
   <Level Value="1" />  <!-- this is the default -->
   <Level Condition="FOO" Value="0" /> <!-- an example -->

If I understand correctly, the issue with this design is that you could do the following:

<Feature ... no Level attribute available>
   <Level Value="2" />
   <Level Value="3" />

The compiler could catch that, but it opens up an error scenario that doesn't need to exist. And it doesn't solve the original problematic issue presented of using a truthy value in the Condition, like so:

<Feature ... no Level attribute available>
   <Level Value="3" />
   <Level Condition="1" Value="1" />

My big debate in v4 was what name to use for the Level element. A better name may have been LevelCondition, but then you'd repeat the element name at the most logical attribute name, like so:

<Feature ...>
   <LevelCondition Condition="FOO" Value="1" />

Honestly, Feature level conditions are rare enough that I don't lose much sleep over using the Level element name. The one I think about more is LaunchConditions which looks like this:

<Package ...>
   <Launch Condition="BLOCK_THE_INSTALL" Message="Your install is blocked for some reason" />

It reads okay when you put the attributes in the "right order" but reads poorly when the attributes are in the opposite order.

[oleg-shilo]

I see your point. And totally agree with your LevelCondition preference. Package.Launch is kinda the same pattern/anti-pattern as Feature.Level :)

---

As for my regarding feature condition, is actually much simpler than it seems. I suggest:

1

The code below should throw a warning "Level" attribute is obsolete. Please use a nested "Level" element instead.

<Feature Id="feature1_" Title="feature1" Level="1" >

And in a few releases deprecate the attribute completely.

---

2

The code below should throw warning #1 and an additional warning warning "Level" attribute value will be ignored. The nested "Level.Value" '1' attribute will take precedence.

<Feature Id="feature1_" Title="feature1" Level="3" >
    <Level Condition="1"/>

---

3

The code below should not throw any warning unless you have very specific feedback from users about dev-experience:

<Feature Id="feature1_" Title="feature1"  >
    <Level Condition="1"/>
    <Level Condition="2"/>

[robmen]

Package.Launch is kinda the same pattern/anti-pattern as Feature.Level

How are these the same anti-pattern?

What Feature Level would this example set?

You still have not convinced me why it is better to use an element instead of an attribute to set the default Feature Level.

[oleg-shilo]

You still have not convinced me why it is better to use an element instead of an attribute to set the default Feature Level.

I was not trying to.

You have missed my point. I was trying to convince you that having both options available is an API antipattern.

I will try again but using a different example.

This is how .NET defines AssemblyName where Version is a custom type (an equivalent of XML element):

public class AssemblyName
{    
    public ProcessorArchitecture ProcessorArchitecture { get; set; }
    public string? Name { get; set; }
    public Version? Version { get; set; }
    . . .
}

If I am designing this type and following your approach I would need to allow access to the nested elements of the Version in the parent class AssemblyName:

public class AssemblyName
{    
    public ProcessorArchitecture ProcessorArchitecture { get; set; }
    public string? Name { get; set; }
    public Version? Version { get; set; }
    public int? MajorVersion { get; set; }
    public int? MinorVersion { get; set; }
    public int? BuildVersion { get; set; }
    public int? RevisionVersion { get; set; }
    . . .
}

I do not see this as a good API design decision.

Let me help you to debate my point. That approach is not completely unheard of in .NET. Even in the very same namespace you will find:

class Assembly
{
    public string? FullName { get; }
    public AssemblyName GetName();
    . . .

But in this case, there is a clear distinction of the intent expressed via different member names and different member types (method vs property). Thus if you ask me this is still an acceptable API design.

However, if C# syntax allows and I redefine this type as:

class Assembly
{
    public string? Name  { get; set; }
    public AssemblyName Name { get; set; }
    . . .

Then I would also consider it as an antipattern.