Add .NET 10 / EF Core 10 / AutoMapper 16 support

[xrkolovos]

Summary

• Add net10.0 target framework alongside existing net8.0 and net9.0
• Update AutoMapper to 16.x, AutoMapper.Collection to 13.x, ExpressionMapping to 10.x
• Use per-TFM EF Core references (8.0.16 / 9.0.7 / 10.0.5) since EF Core 10 only supports net10.0
• Update test dependencies: FluentAssertions 8.9.0, xunit 2.9.3, Microsoft.NET.Test.Sdk 18.3.0
• Update tooling: Roslynator 4.15.0, MinVer 7.0.0
• Add setup-dotnet step to CI/release workflows for all required SDKs

Test plan

• Build succeeds for all 3 TFMs (net8.0, net9.0, net10.0)
• All 180 tests pass (60 per TFM)
• CI pipeline passes with .NET 10 SDK setup

[xrkolovos]

@dotnet-policy-service agree company="egritosgroup"

[xrkolovos]

@jbogard who can check and accept this?
thank you

[aarondglover]

@jbogard who can check and accept this? thank you

@jbogard I am blocked without this package supporting v16

[aarondglover]

@xrkolovos can you request a PR review from Jimmy?

[xrkolovos]

@lbargaoanu @Nicot3 can you merge this pr? thank you

[Nicot3]

@xrkolovos I've just have a quick look without testing or building but, it is possible to add more versions? For example, AutoMapper.Extensions on version 12 is compatible with .NET 10, and with this change is not going to be possible to use this version anymore. This will force update to some people that maybe don't need to update his dependencies.

I'm not 100% sure anyways, need to investigate a bit more or get a second opinion 😄

[ahmed-abdelrazek]

merge so people can update and avoid the new security vulnerability then solve your dependencies issues in another pr @Nicot3

[xrkolovos]

@xrkolovos I've just have a quick look without testing or building but, it is possible to add more versions? For example, AutoMapper.Extensions on version 12 is compatible with .NET 10, and with this change is not going to be possible to use this version anymore. This will force update to some people that maybe don't need to update his dependencies.

I'm not 100% sure anyways, need to investigate a bit more or get a second opinion 😄

do this with a seperated pull request

@Nicot3 it will be a realease soon?

[Nicot3]

@xrkolovos I don't have permissions on the repo, I can just approve 😅

[xrkolovos]

@jbogard can you please approve this changes and make a release?

[ahmed-abdelrazek]

another reason to let ai replace automapper for https://github.com/riok/mapperly ??

[Nicot3]

@ahmed-abdelrazek

another reason to let ai replace automapper for https://github.com/riok/mapperly ??

I did a quick read to Mapperly and doesn't have to seem the advantage of Dependency Injection.
Maybe Mapster is a good alternative, it has DI and also cool features like autogeneration of DTOs. Never tested it, but for sure I will do

[aarondglover]

@ahmed-abdelrazek

another reason to let ai replace automapper for https://github.com/riok/mapperly ??

I did a quick read to Mapperly and doesn't have to seem the advantage of Dependency Injection. Maybe Mapster is a good alternative, it has DI and also cool features like autogeneration of DTOs. Never tested it, but for sure I will do

Auto-generated DTOs!
DTOs are not just an implementation detail — they form a core part of the public API contract. They define what external consumers rely on, and as such, they need to be explicit, stable, and versioned deliberately.

Having DTOs change automatically because an underlying domain model changed feels risky. It effectively couples your API surface directly to internal implementation details, which can lead to:

• Unintentional breaking changes
• Loss of control over API versioning
• Downstream instability for API consumers
  Increased difficulty in maintaining backward compatibility

In practice, this means a simple internal refactor could ripple out and break clients without any conscious decision to do so.

For internal-only mappings this might be fine, but for externally exposed APIs, I’d strongly prefer DTOs to remain explicitly defined and intentionally evolved, rather than implicitly generated.

To me, the convenience here doesn’t outweigh the loss of control over something as critical as the API contract.

[ahmed-abdelrazek]

mapperly is just an easy fast way to do manual mapping using source generation and for the most part it doesn't need di

[Nicot3]

@aarondglover I totally agree your point, for public contracts like APIs this needs to be consistent and should not change on each build because it can leads for broken contracts. But as you mention, for internal mappings it can reduce a lot of work.

For now I didn't it on this way as on most of my projects I'm still using Automapper, but if I should change my library I will totally go with that one because the number of features it has are bigger an useful.

@ahmed-abdelrazek

another reason to let ai replace automapper for https://github.com/riok/mapperly ??

I did a quick read to Mapperly and doesn't have to seem the advantage of Dependency Injection. Maybe Mapster is a good alternative, it has DI and also cool features like autogeneration of DTOs. Never tested it, but for sure I will do

Auto-generated DTOs! DTOs are not just an implementation detail — they form a core part of the public API contract. They define what external consumers rely on, and as such, they need to be explicit, stable, and versioned deliberately.

Having DTOs change automatically because an underlying domain model changed feels risky. It effectively couples your API surface directly to internal implementation details, which can lead to:

* Unintentional breaking changes

* Loss of control over API versioning

* Downstream instability for API consumers
  Increased difficulty in maintaining backward compatibility

In practice, this means a simple internal refactor could ripple out and break clients without any conscious decision to do so.

For internal-only mappings this might be fine, but for externally exposed APIs, I’d strongly prefer DTOs to remain explicitly defined and intentionally evolved, rather than implicitly generated.

To me, the convenience here doesn’t outweigh the loss of control over something as critical as the API contract.

[jbogard]

Just an FYI folks, I'm not the maintainer of ANY of the repositories here. I'm only a maintainer on the main AutoMapper repo. I have no idea what's going on in any of these repos.