Possible regression / changed behavior in v10: `CasesCount` no longer maps from `Cases.Count` automatically

[NikolayIT]

Hi,

after upgrading Mapster from v7 to v10, I noticed a behavior change that used to work for us without explicit custom mapping.

What changed

We have a destination/view model property like:

public int CasesCount { get; set; }

and a source entity with a collection:

public ICollection<Case> Cases { get; set; }

In Mapster v7, CasesCount was populated automatically (effectively from Cases.Count) even without any explicit .Map(...) configuration.

After upgrading to v10, the same property now gets value 0.

Question

Was this behavior intentionally changed in v10?

• If yes, was it ever officially supported, or was it only incidental behavior?
• If no, could this be a regression?

Minimal example

public class Source
{
    public ICollection<Case> Cases { get; set; } = new List<Case>
    {
        new Case(),
        new Case(),
        new Case()
    };
}

public class Case
{
}

public class Destination
{
    public int CasesCount { get; set; }
}

Expected: CasesCount == 3
Actual: CasesCount == 0

[DocSvartz]

Hi @NikolayIT. This is due to changes in the detection of record types. #537

If yes, was it ever officially supported, or was it only incidental behavior?

Considering that this wasn't explicitly verified in any of the tests, it only incidental behavior.

Flatten mapping was and is supported, only for Poco or record types.

*Poco is type have any property with setter

[NikolayIT]

Thanks for the clarification.

That makes sense. In that case, please consider this issue a feature request rather than a bug report.

It would be very useful if Mapster could optionally support this kind of convention-based mapping for collection counts, for example:

• CasesCount -> Cases.Count
• ItemsCount -> Items.Count

I understand this was only incidental behavior before, but it seems like a natural and practical extension of flatten mapping, especially for DTO/view model scenarios.

There is also precedent for this kind of convention in AutoMapper. In its projection/aggregation support, destination members such as ContactsCount can be matched to Count() over a child collection. That makes this convention quite intuitive from a consumer perspective as well.

Even if not enabled by default, support through an opt-in setting or convention would be very helpful.

Thanks again.

[DocSvartz]

Actually, I don't really understand what prompted the initial choice. Poco and Record. 🤔
At first glance, there shouldn't be any problems in other cases either.

@NikolayIT The problem here is precisely in the interface. If you use a "real collection", you'll get the desired result. (poco condition will be met) 😅

public class Source
{
    public List<Case> Cases { get; set; } = new List<Case>
    {
        new Case(),
        new Case(),
        new Case()
    };
}

[NikolayIT]

Thanks, that helps clarify it.

In my case I am using ICollection<T> intentionally, because this is the usual shape for EF Core collection navigations and the pattern we use across the project.

So for us this is not really an artificial edge case — it is the normal EF Core scenario.

For example:

public class Source
{
    public ICollection<Case> Cases { get; set; } = new List<Case>
    {
        new Case(),
        new Case(),
        new Case()
    };
}