Dynamically ignore members

I’m trying to only emit certain properties as elements in certain situations. For example:

public class Leistungszeitraum
{
    public enum LeistungszeitraumTyp
    {
        Tag = 1,
        Monat
    }

    [XmlAttribute]
    public LeistungszeitraumTyp Typ { get; set; }

    public DateTime Tag { get; set; }
    public string Monat { get; set; }

    //[EditorBrowsable(EditorBrowsableState.Never)]
    //public bool ShouldSerializeTag()
    //    => Typ == LeistungszeitraumTyp.Tag;

    //[EditorBrowsable(EditorBrowsableState.Never)]
    //public bool ShouldSerializeMonat()
    //    => Typ == LeistungszeitraumTyp.Monat;
}

With classic XmlSerializer, I can accomplish this with the commented-out ShouldSerialize* members. This doesn’t appear to be supported by ExtendedXmlSerializer. Instead, this comment suggests using EmitWhen, but that doesn’t appear to work for me:

var serializer = new ConfigurationContainer()
                 .Type<Leistungszeitraum>(c =>
                 {
                     c.Member(x => x.Tag).EmitWhen(x => x.Typ == Leistungszeitraum.LeistungszeitraumTyp.Tag);
                     c.Member(x => x.Monat).EmitWhen(x => x.Typ == Leistungszeitraum.LeistungszeitraumTyp.Monat);
                 })
                 .Create();

Instead, this apparently defines whether the entire type gets emitted or not.

Do I need to use the other overload of Member()?

[chucker]

Sorry, hadn’t gotten a chance to test it. It works as expected.

Regarding the package, I had to remove it from the local package cache and make sure the custom feed was listed before nuget.org (makes sense, but someone else may overlook this part). Is there a reason you aren’t simply giving the package its own pre-release version, like 2.1.4-issue182? That would fix the caching/precedence issues. (Does the CI not support this?)

Anyway, thanks for implementing this!

[Mike-E-angelo]

Boh… thanks for pointing this out @chucker. It’s sort of funny that I absolutely hate the ShouldSerialize* magic string/definition conventions but I never put in a suitable replacement. 😆 It’s technically an enhancement but really it’s a bug. I will try to have something for you by EOD today to remedy this.