After six years without a new stable release, Dapper FluentMap is actively maintained again. But bringing an existing library back to life involves more than updating dependencies. It means finding a way to move forward without breaking the contracts that existing applications rely on.

Imagine a .NET application that uses Dapper to query a legacy database. In the code, we have a Customer entity with properties such as Id and Name . In the database, the columns follow a different naming convention: customer_id and customer_name .

Handling this difference is not particularly difficult. We can use SQL aliases, introduce intermediate objects, or configure explicit mappings. All are reasonable approaches, depending on the context.

The problem becomes more noticeable when these differences spread across dozens of queries and entities.…