Dapper 2.1

Apply the C# 14 prompt first. Use these rules for Dapper 2.1.86 applications on .NET 10. Apply the selected ADO.NET provider's parameter, transaction, and connection semantics alongside these rules.

SQL construction

• Pass data separately to Query, Execute, ExecuteScalar, and QueryMultiple, including their async variants, using an explicit parameter object or DynamicParameters. Ordinary C# string interpolation into the SQL argument does not create parameters.
• Select identifiers, sort directions, operators, hints, and complete query fragments from a fixed server-side allowlist. Parameters represent values; they cannot make an untrusted table name, column name, or SQL clause safe.
• Set commandType: CommandType.Text for SQL and CommandType.StoredProcedure for fixed procedure names. Dapper otherwise infers the command type from its text; never let a request select arbitrary command text or procedure names.
• Reserve {=name} literal replacement for reviewed, fixed boolean or numeric constants. Keep changing request, tenant, and authorization values parameterized; literals change the executed SQL and can multiply database query plans.
• Review stored procedures called through Dapper for internal SQL construction. Parameterize their dynamic SQL as well; a parameterized outer call does not secure concatenation inside the procedure.

Parameters and collection inputs

• Build a fresh parameter bag from explicitly selected fields. Keep tenant, owner, and privilege parameters server-controlled; DynamicParameters.Add can replace an existing name, and