If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/DapperLib/Dapper shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 1w ago
• 26+ active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 65% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live DapperLib/Dapper repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/DapperLib/Dapper.

What it runs against: a local clone of DapperLib/Dapper — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in DapperLib/Dapper | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 40 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of DapperLib/Dapper. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/DapperLib/Dapper.git
#   cd Dapper
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of DapperLib/Dapper and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "DapperLib/Dapper(\\.git)?\\b" \\
  && ok "origin remote is DapperLib/Dapper" \\
  || miss "origin remote is not DapperLib/Dapper (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Dapper/SqlMapper.cs" \\
  && ok "Dapper/SqlMapper.cs" \\
  || miss "missing critical file: Dapper/SqlMapper.cs"
test -f "Dapper/SqlMapper.Async.cs" \\
  && ok "Dapper/SqlMapper.Async.cs" \\
  || miss "missing critical file: Dapper/SqlMapper.Async.cs"
test -f "Dapper/DynamicParameters.cs" \\
  && ok "Dapper/DynamicParameters.cs" \\
  || miss "missing critical file: Dapper/DynamicParameters.cs"
test -f "Dapper/SqlMapper.ITypeMap.cs" \\
  && ok "Dapper/SqlMapper.ITypeMap.cs" \\
  || miss "missing critical file: Dapper/SqlMapper.ITypeMap.cs"
test -f "Dapper/SqlMapper.GridReader.cs" \\
  && ok "Dapper/SqlMapper.GridReader.cs" \\
  || miss "missing critical file: Dapper/SqlMapper.GridReader.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 40 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~10d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/DapperLib/Dapper"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Dapper is a high-performance micro-ORM for .NET that maps query results directly to .NET objects with minimal overhead. It sits between raw ADO.NET (fast, verbose) and Entity Framework (convenient, heavy), providing speedy object-to-relational mapping without the bloat—Core is in Dapper/Dapper.csproj with extension packages for EntityFramework integration (Dapper.EntityFramework), bulk operations (Dapper.ProviderTools), and query building (Dapper.SqlBuilder). Multi-project monorepo: Dapper/ is the core ORM engine with extension packages as peers—Dapper.SqlBuilder (dynamic query builder), Dapper.EntityFramework (DbGeography/DbGeometry type handlers), Dapper.ProviderTools (BulkCopy, DbException helpers), Dapper.Rainbow (Database<T> abstraction), and StrongName variants for legacy signing. Build.csproj orchestrates multi-target compilation; PublicAPI.Shipped.txt/Unshipped.txt in each package enforce semver discipline.

.NET backend developers who need sub-millisecond query performance while retaining type safety and LINQ-style API; common in high-traffic StackOverflow infrastructure and financial services where ORM overhead matters. Contributors include maintainers optimizing for latency-sensitive scenarios and users adding database provider support.

Production-ready and actively maintained. The project has ~1.14M lines of C# across core + extensions, maintained strong CI/CD (GitHub Actions in .github/workflows/main.yml), and multiple stable NuGet packages with millions of downloads. Recent development is ongoing (visible in release notes and MyGet pre-release feeds), though commit frequency data is not shown here—check Git log to confirm current velocity.

Low risk for core functionality but dependency on database provider vagaries exists. Major risk: single monorepo with tight coupling between Dapper core and extensions (Dapper.EntityFramework, Dapper.ProviderTools, Dapper.Rainbow); breaking changes to core IL-generation or parameter handling impact all. Strong Name variants (Dapper.StrongName, Dapper.EntityFramework.StrongName) suggest legacy compatibility burden. No obvious abandonment signals, but verify last commit date against release schedule.

No explicit recent changes are visible in the file list provided. Check GitHub Actions workflow (main.yml) for recent build status, and the Releases page (linked in README) for latest version changes. CLA workflow (cla.yml) suggests active contributor onboarding.

git clone https://github.com/DapperLib/Dapper.git && cd Dapper && dotnet restore && dotnet build Build.csproj. No npm/PowerShell setup needed for core; Build.csproj handles multi-targeting. Open Dapper.sln in Visual Studio or VS Code.

Daily commands: dotnet build Build.csproj builds all projects. No 'dev server'—this is a library. For testing: dotnet test (check for Test project, not visible in top 60 files; locate Tests/ or *.Tests.csproj in full repo). Publish to NuGet locally: dotnet pack Dapper/Dapper.csproj -o ./nupkg -c Release.

• Dapper/SqlMapper.cs — Core entry point and main API surface—contains Query, Execute, and GridReader methods that all other functionality builds upon.
• Dapper/SqlMapper.Async.cs — Async variants of all primary data access methods; essential for understanding non-blocking query execution.
• Dapper/DynamicParameters.cs — Parameter binding and caching mechanism that directly impacts query performance and SQL injection prevention.
• Dapper/SqlMapper.ITypeMap.cs — Core abstraction for object-to-database mapping; defines how deserialization and type resolution work.
• Dapper/SqlMapper.GridReader.cs — Multi-result-set reader implementation; critical for understanding how Dapper handles complex queries returning multiple shapes.
• Dapper/SqlBuilder/SqlBuilder.cs — Fluent SQL composition library used for dynamic query building; foundational for extension patterns.
• Dapper/CommandDefinition.cs — Command metadata container that encapsulates query, parameters, and execution flags; used by all Query/Execute overloads.

Add a Custom Type Handler

1. Create a class implementing SqlMapper.ITypeHandler<T> in a new file (e.g., Dapper/MyCustomTypeHandler.cs) (Dapper/SqlMapper.ITypeHandler.cs)
2. Implement Parse() to convert from DbDataReader, and SetValue() to map CLR to DbParameter (Dapper/SqlMapper.TypeHandler.cs)
3. Register the handler with SqlMapper.AddTypeHandler<T>(new MyCustomTypeHandler()) in initialization code (Dapper/SqlMapper.cs)
4. Use the custom type in Query<T> or Execute calls—Dapper will automatically invoke your handler (Dapper/SqlMapper.Async.cs)

Add Custom Property-to-Column Mapping

1. Create a CustomPropertyTypeMap instance with your mapping dictionary (Dapper/CustomPropertyTypeMap.cs)
2. Pass it to SqlMapper.SetTypeMap<T>() to register globally, or use CommandDefinition with custom type map (Dapper/CommandDefinition.cs)
3. Execute Query<T> or QueryAsync<T> with that CommandDefinition; Dapper will use your custom mappings (Dapper/SqlMapper.cs)

Build a Dynamic SQL Query with SqlBuilder

1. Create a SqlBuilder instance and use /**/ comment blocks with Append() to define query template (Dapper/SqlBuilder/SqlBuilder.cs)
2. Call Where(), OrderBy(), and other builder methods to compose clauses conditionally (Dapper/SqlBuilder/SqlBuilder.cs)
3. Call builder.AddTemplate() to finalize the query template string (Dapper/SqlBuilder/SqlBuilder.cs)
4. Pass the template.RawSql and template.Parameters to Query<T> or Execute via CommandDefinition (Dapper/CommandDefinition.cs)

Execute Query with Output Parameters

1. Create DynamicParameters and use Add() with direction=ParameterDirection.Output for each output param (Dapper/DynamicParameters.cs)
2. Call Query<T> or Execute with the DynamicParameters instance (Dapper/SqlMapper.cs)
3. After execution, retrieve output values from parameters.Get<T>(paramName) (Dapper/DynamicParameters.cs)

• .NET Standard 2.0 + net461 + net8.0 multi-target — Ensures compatibility across legacy .NET Framework, modern .NET Core, and latest .NET versions; maximizes library reachability
• IL generation for deserialization — Reflection-based mapping is slow; compiling IL at query-plan time and caching it provides performance equivalent to hand-written code while remaining flexible
• DbDataReader abstraction (IDataReader wrapping) — Database-agnostic: works with any DbConnection (SQL Server, PostgreSQL, MySQL, SQLite, etc.) without provider-specific code
• Dynamic parameters with SqlParameter caching — Prevents SQL injection, centralizes parameter binding logic, caches compiled output-parameter setters for repeated calls
• GridReader for multi-result-set queries — Single round-trip for multiple queries; dramatically reduces network overhead in complex stored procedures or UNION queries

• Minimal by design—no relationships, no change tracking, no lazy loading

  • Why: Dapper targets high-performance scenarios where explicit control is valued; full ORM features add overhead and lock-in
  • Consequence: Developers must manually manage related entities, but queries are faster and more predictable

• Query plans cached globally in ConcurrentDictionary, not per-connection or per-session

  • Why: Reduces memory footprint and speeds up repeated queries across the application
  • Consequence: Unbounded cache could theoretically grow if unlimited unique queries are generated; requires manual cache clearing in edge cases

• Deserialization is compiled to IL and cached by type signature (type+column names)

  • Why: Orders of magnitude faster than reflection for large result sets
  • Consequence: First query of a new type is slower (IL compilation); cache collision if same columns map to different CLR properties in different calls

IL-generation caching: SqlMapper internally caches IL-compiled readers and writers by type + query shape; clearing cache for custom type maps requires explicit setup (check ITypeMap implementations). Strong Name assemblies (.snk file present) create parallel NuGet packages—ensure your app references consistent versions across Dapper and extensions (mixing unsigned + signed = binding errors). No Entity Framework dependency in core despite Dapper.EntityFramework package—only DbGeography/DbGeometry from System.Data.Entity; confirm EF version compatibility in consuming projects. Dynamic parameters use type-name matching for output setters; misspelled property names silently fail to populate (no validation at query time).

• IL Code Generation for Dynamic Mapping — Dapper's core performance advantage comes from runtime IL emission to create fast property setters/getters; understanding Reflection.Emit vs. reflection vs. Expression Trees is essential for debugging custom type maps and optimizing hot paths
• Micro-ORM Pattern — Dapper exemplifies the micro-ORM philosophy (thin wrapper around ADO.NET) vs. full ORMs; knowing where to use Dapper vs. EF/Linq2Sql is critical for architecture decisions in this codebase
• IDataReader / ADO.NET Type Mapping — Dapper wraps IDataReader extension methods; understanding how SqlDataReader columns map to CLR types (including nullable, enum, custom) is essential for type handler implementation and debugging result binding
• Parameter Escaping & SQL Injection Prevention — Dapper's DynamicParameters and SqlBuilder escape parameter names and values; knowing how parameterized queries prevent injection attacks is critical when modifying parameter handling or SQL generation
• Expression Trees & Compilation — CustomPropertyTypeMap and type mapping logic leverage Expression.Compile() for dynamic property access; understanding Expression API is needed for custom type map extensions
• Multi-Targeting & Framework Compatibility — Build.csproj targets multiple .NET versions (.NET Framework 4.6.1, .NET Standard 2.0, .NET 6+); understanding conditional compilation and platform differences (DbGeometry spatial types) is needed for cross-version fixes
• Semantic Versioning & Public API Contracts — PublicAPI.Shipped.txt / PublicAPI.Unshipped.txt in each package enforce strict semver; Dapper is a library, so breaking changes have massive downstream impact—this file enforces discipline

• dotnet/efcore — Entity Framework Core is the heavier, feature-complete ORM alternative; Dapper is often chosen when EF's performance/complexity trade-off is unfavorable
• NPoco/NPoco — Direct competitor micro-ORM with similar Goals (speed, simplicity) but different design choices; reference for comparative feature parity
• FreeSql/FreeSql — Modern C# ORM offering micro-ORM simplicity + dynamic query building; comparison for architecture patterns and performance
• StackExchange/StackExchange.Redis — Sibling StackExchange project demonstrating same engineering philosophy (minimal dependencies, high performance, .NET ecosystem focus)
• DapperLib/Dapper.Contrib — Official extension adding CRUD helpers and attribute-based conventions (Insert, Update, Delete, Get) on top of core Dapper

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive async/await tests for Dapper.Rainbow Database operations

Dapper.Rainbow/Database.Async.cs exists alongside Database.cs, but there's no evidence of dedicated async test coverage in the repo structure. Given that async is critical for modern .NET applications and Dapper is frequently used in async contexts, comprehensive tests comparing sync vs async behavior (especially around connection handling, transaction management, and result materialization) would catch regressions early.

• [ ] Create Tests/Dapper.Rainbow.Async.Tests.cs with test cases for Database.QueryAsync, QueryFirstOrDefaultAsync, InsertAsync, UpdateAsync, DeleteAsync
• [ ] Add parameterized tests comparing sync vs async behavior for connection state and transaction handling
• [ ] Test cancellation token support across all async methods
• [ ] Reference Dapper.Rainbow/Database.Async.cs to ensure all public async methods are covered

Add provider-specific integration tests for Dapper.ProviderTools bulk copy functionality

Dapper.ProviderTools/BulkCopy.cs and Internal/DynamicBulkCopy.cs implement provider-specific bulk operations, but there are no visible provider-specific test workflows. Different SQL providers (SQL Server, PostgreSQL, SQLite, MySQL) have different bulk copy APIs and constraints. Adding provider-specific integration tests would catch behavioral differences and regressions.

• [ ] Create .github/workflows/provider-integration-tests.yml with matrix testing for SQL Server, PostgreSQL, SQLite
• [ ] Add Tests/Dapper.ProviderTools.Integration/ with provider-specific test classes inheriting a base test suite
• [ ] Test BulkCopy.cs against Dapper.ProviderTools/DbConnectionExtensions.cs to validate bulk operations per provider
• [ ] Include tests for edge cases: empty datasets, large datasets, data type mappings per provider

Create comprehensive documentation for CustomPropertyTypeMap with examples in Dapper/CustomPropertyTypeMap.cs

CustomPropertyTypeMap.cs exists but there's no dedicated documentation file explaining when and how to use custom type mapping vs DefaultTypeMap. This is a frequently-asked question for Dapper users. Adding Dapper/CustomPropertyTypeMap.md with concrete examples would reduce support burden and improve contributor understanding.

• [ ] Create Dapper/CustomPropertyTypeMap.md documenting the purpose and API of Dapper/CustomPropertyTypeMap.cs
• [ ] Include examples: custom enum mapping, database-specific type handling, constructor parameter mapping
• [ ] Add performance considerations and when to use CustomPropertyTypeMap vs ExplicitConstructorAttribute (Dapper/ExplicitConstructorAttribute.cs)
• [ ] Link this documentation from the main README.md and consider adding to Dapper/PublicAPI/ documentation structure

• Add missing test coverage for Dapper/CompiledRegex.cs—regex patterns for SQL parsing should have explicit unit tests for edge cases (nested brackets, quoted identifiers in parameter names)
• Document the ITypeMap interface and DefaultTypeMap/CustomPropertyTypeMap behaviors in a code example within Dapper/ or wiki—currently no examples show how to override property-to-column mapping for custom naming conventions
• Add async overloads (Async.cs partial) for Dapper.Rainbow/Database.cs classes—currently only sync methods exist; async support would match QueryAsync<T> in core SqlMapper

The Dapper codebase demonstrates solid security foundation as an ORM library with built-in

• High · SQL Injection Risk in Dynamic Query Building — Dapper/SqlBuilder/SqlBuilder.cs, Dapper/SqlMapper.*.cs. The codebase includes SqlBuilder.cs and multiple SqlMapper files that handle dynamic SQL query construction. Without visible input validation and parameterization enforcement patterns, there is a potential risk of SQL injection if developers construct queries without proper parameter binding. Dapper's core value is safe parameterized queries, but misuse of raw SQL concatenation could bypass this. Fix: Ensure all documentation emphasizes mandatory use of parameterized queries. Add code examples showing secure patterns. Consider implementing linting rules or analyzers to detect raw SQL concatenation. Audit the public API for any methods that accept raw SQL without clear parameter binding requirements.
• Medium · Potential Unsafe Deserialization — Dapper/SqlMapper.DeserializerState.cs, Dapper/DefaultTypeMap.cs, Dapper/CustomPropertyTypeMap.cs. Multiple deserialization components exist (SqlMapper.DeserializerState.cs, DefaultTypeMap.cs, CustomPropertyTypeMap.cs) that map database results to objects. If malicious data sources are used or if complex type handling isn't properly validated, there could be deserialization attacks or type confusion vulnerabilities. Fix: Implement strict type validation during deserialization. Validate that mapped types are expected types. Consider using whitelist-based type mapping. Add security documentation about using untrusted data sources. Review type instantiation patterns for potential gadget chain vulnerabilities.
• Medium · Dynamic Type Instantiation Risk — Dapper/SqlMapper.DapperRow.cs, Dapper/DynamicParameters.cs, Dapper/DynamicParameters.CachedOutputSetters.cs. Files like SqlMapper.DapperRow.cs and dynamic parameter handling (DynamicParameters.cs) use reflection and dynamic object creation. If not carefully controlled, this could allow instantiation of unintended types or invocation of arbitrary methods. Fix: Implement strict controls on which types can be dynamically instantiated. Use type validation and reflection security checks. Document restrictions on dynamic type usage. Consider limiting reflection to safe type sets. Review CachedOutputSetters for proper setter validation.
• Medium · Missing Input Validation in DbString Handler — Dapper/DbString.cs. DbString.cs provides database string handling. Without proper validation of string inputs, length constraints, and encoding, there could be buffer overflow, encoding issues, or truncation attacks that bypass security measures. Fix: Implement strict input validation including length limits, character encoding validation, and proper Unicode handling. Add security documentation for DbString usage. Consider implementing maximum length enforcement at the parameter level.
• Low · StrongName Key File Exposed in Repository — Dapper.snk. The file 'Dapper.snk' (strong name key file) is present in the repository. While this is a public repository and strong names have reduced security value in modern .NET, this could still be considered a security configuration issue if the key needs to be protected. Fix: Evaluate if strong naming is still necessary for security purposes. If the key should be protected, move it to a secure key management system and use environment-based signing in CI/CD. Document the strong naming strategy.
• Low · No Visible Security Documentation — Root repository directory. The README and file structure show no dedicated SECURITY.md file or security policy documentation, making it unclear how security issues should be reported or what security practices are followed. Fix: Create a SECURITY.md file documenting: security reporting process, supported versions, security best practices for users, and security considerations for common use cases. Add security section to main README.
• Low · Bulk Copy Operations Security Considerations — Dapper.ProviderTools/BulkCopy.cs. Dapper.ProviderTools includes BulkCopy.cs which performs bulk data operations. Without explicit security considerations documented, users might not be aware of potential risks with large-scale data operations or privilege escalation through bulk operations. Fix: Add security documentation for bulk operations, including: required database permissions, potential performance DoS risks with extremely large datasets, recommendations for transaction handling and error recovery. Implement operation size limits if applicable.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.