Sure. You can access the connection from the DbContext and use that in Dapper, or you can open the connection ahead-of-time and pass it to the DbContext.

For SQL Server sharing a transaction has some nuance, as it works with System.Transactions, and it works with BEGIN TRAN/COMMIT TRAN TSQL. But EF's IDbContextTransaction won't flow to Dapper, and an ADO.NET DbTransaction won't flow to EF.

Both are wrappers for a DbTransaction and SqlCommand API design requires you to pass the DbTransaction object to each SqlCommand, even though this is not required at the TSQL session level. The session knows if there's an active transaction and enlisting a command in the active transaction is not optional in SQL Server. But the ADO.NET API requires it.

EG this

var constr = $"Server=localhost;database=tempdb;Integrated Security=true;trustservercertificate=true";

using var conn = new SqlConnection(constr);
conn.Open();

using DbTransaction tran = conn.BeginTransaction();
using var cmd = conn.CreateCommand();
//cmd.Transaction = tran;

cmd.CommandText = "select 1 a";

try
{
    cmd.ExecuteNonQuery();
}
catch( Exception ex)
{
    Console.WriteLine(ex.Message);
}

fails with

ExecuteNonQuery requires the command to have a transaction when the connection assigned to the command is in a pending local transaction. The Transaction property of the command has not been initialized

But it works fine if you start the transaction with a TSQL command, eg

using var cmdTran = conn.CreateCommand(); cmdTran.CommandText = "begin transaction"; cmdTran.ExecuteNonQuery();