Skip to content

v3.4.0

Choose a tag to compare

@github-actions github-actions released this 28 Sep 14:22
· 71 commits to main since this release
d873f74

Dapper.FluentMap 3.4.0

Dapper.FluentMap 3.4.0 expands the maintained 3.x line with first-class multi-mapping, asynchronous multiple-result-set APIs, stricter generated materialization, broader database-provider certification, and a hardened release supply chain.

This release keeps the core packages on netstandard2.0 while substantially increasing the behavior validated by the project's automated compatibility matrix.

Highlights

FluentMap-controlled multi-mapping

FluentMap now provides first-class two-type multi-mapping through:

QueryMapped<TFirst, TSecond, TReturn>(...)

The API supports:

  • splitOn boundaries;

  • per-segment mapping profiles;

  • immutable objects;

  • nested mappings;

  • value objects;

  • property converters;

  • Dapper TypeHandler interoperability;

  • isolated FluentMapRuntime configuration.

LEFT JOIN scenarios are also handled so an absent child segment can be represented correctly instead of materializing an invalid object.

Async multiple-result-set materialization

The mapped multiple-result API now includes asynchronous counterparts:

QueryMultipleMappedAsync(...)
ReadMappedAsync<T>(...)
ReadMappedSingleAsync<T>(...)
ReadMappedSingleOrDefaultAsync<T>(...)

MappedGridReader preserves ordered result-set consumption and now rejects concurrent reads deterministically, while supporting cancellation and predictable disposal behavior.

Strict generated materialization

Applications that want to avoid runtime materialization fallback can now opt into a generated-only path using:

UseStrictGeneratedMaterialization()
QueryGeneratedMapped*()

Unsupported shapes fail deterministically instead of silently falling back to reflection-based runtime materialization.

Generated materializers also support safe permutations of distinct result columns, improving generated-path coverage for projections whose column order differs from the registered shape.

A dedicated Native AOT smoke test validates the strict generated SQLite path on win-x64.

Full Native AOT compatibility is not claimed. Reflection-based assembly scanning, arbitrary runtime fallback, and other dynamic scenarios remain outside the supported Native AOT boundary.

Provider certification

Provider compatibility is now continuously validated against real database instances in CI.

Provider | Validated version -- | -- SQLite | Microsoft.Data.Sqlite 10.0.12 SQL Server | SQL Server 2022 CU23 / Microsoft.Data.SqlClient 7.1.0 PostgreSQL | 18.6 / Npgsql 10.0.3 MySQL | 8.4.11 / MySqlConnector 2.6.2 MariaDB | 11.8.9 / MySqlConnector 2.6.2

The SQL Server, PostgreSQL, MySQL, and MariaDB lanes are mandatory and fail closed when the database service or test configuration is unavailable.

These tests exercise mapped reads, generated/runtime materialization, multiple result sets, streaming, and relevant Dommel persistence scenarios.

Dapper compatibility

The supported Dapper range is now consistently defined and tested as:

Dapper [2.1.79, 3.0.0)

The CI matrix validates both:

  • minimum supported: 2.1.79

  • latest stable: 2.1.89

This aligns package metadata, documentation, and the versions exercised by CI.

Package family

The 3.4.0 release contains:

  • Dapper.FluentMap

  • Dapper.FluentMap.Dommel

  • FluentMap.DependencyInjection

  • FluentMap.Analyzers

  • FluentMap.Generators

The FluentMap.* names are NuGet PackageIds only. Assemblies, namespaces, and public APIs remain under Dapper.FluentMap.*.

All packages continue to target netstandard2.0.

Release and supply-chain hardening

The release pipeline now provides stronger artifact verification and provenance, including:

  • CodeQL analysis;

  • dependency review gates;

  • deterministic package inventory;

  • SHA-256 checksums;

  • SPDX 2.3 SBOM generation;

  • GitHub artifact attestations;

  • release artifact manifest;

  • consumer smoke tests;

  • validation of existing NuGet artifacts before publication;

  • governed publication to NuGet.org and GitHub Packages.

Release and recovery workflows have also been aligned with the repository's main branch.

Compatibility notes

The historical static APIs remain available, including:

FluentMapper.Initialize(...)
EntityMap<TEntity>
Map(...).ToColumn(...)
Ignore()

For applications that need isolated FluentMap configuration, prefer FluentMapConfigurationBuilder and FluentMapRuntime.

The following remain intentionally outside the current compatibility claims:

  • Dapper versions outside [2.1.79, 3.0.0);

  • Dommel versions outside [3.5.3, 4.0.0);

  • full Native AOT compatibility;

  • per-runtime isolation of Dommel's global configuration;

  • three-or-more-type multi-mapping;

  • graph aggregation;

  • CRUD generation.

Upgrade from 3.0.x

Existing applications using the historical FluentMap APIs can continue using them.

When upgrading, keep all FluentMap packages on the same release version and review the newer APIs only where they provide value to your application:

  • use FluentMapRuntime when configuration isolation is required;

  • use QueryMapped<TFirst,TSecond,TReturn> for FluentMap-controlled two-type multi-mapping;

  • use QueryMultipleMappedAsync for asynchronous multiple-result processing;

  • use strict generated materialization when deterministic generated-only behavior is required.

For applications consuming the auxiliary DI, analyzer, or generator packages, use the current PackageIds:

FluentMap.DependencyInjection
FluentMap.Analyzers
FluentMap.Generators

Thank you

Thanks to everyone who has used, tested, reported issues, reviewed changes, or contributed to the continued maintenance of Dapper.FluentMap.

Full changelog:
v3.0.3...v3.4.0