Repository navigation
v3.4.0
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:
splitOnboundaries;per-segment mapping profiles;
immutable objects;
nested mappings;
value objects;
property converters;
Dapper
TypeHandlerinteroperability;isolated
FluentMapRuntimeconfiguration.
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.2The 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.FluentMapDapper.FluentMap.DommelFluentMap.DependencyInjectionFluentMap.AnalyzersFluentMap.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
FluentMapRuntimewhen configuration isolation is required;use
QueryMapped<TFirst,TSecond,TReturn>for FluentMap-controlled two-type multi-mapping;use
QueryMultipleMappedAsyncfor 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.GeneratorsThank 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