When connecting from EF and externally in a TransactionScope, escalation to a distributed transaction occurs in 10 where it didn't previously

[dde-inx]

Question

I recently migrated my solution to .net 10-rc.1.
If I migrate Ef 9 to Ef 10-rc.1 as well, using both EF and Dapper in the same transaction raises with this error: System.NotSupportedException
Implicit distributed transactions have not been enabled. If you're intentionally starting a distributed transaction, set TransactionManager.ImplicitDistributedTransactions to true.

Both EF and Dapper are using the same connection string, dapper uses a separate SqlConnection.
Note that it works perfectly well if I keep my solution using Ef9 with .net 9 or Ef9 with .net 10-rc.1.
Dapper version is the same in all setups.

I didn't find any references of a such a change of behavior in the documentation: https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-9.0/breaking-changes.

Is there any change Ef 10 that is is at the origin of this new behavior ? Do you have some recommendations ?

Your code

I Cannot provide the source code for confidentiality reasons.

Stack traces

System.NotSupportedException: Implicit distributed transactions have not been enabled. If you're intentionally starting a distributed transaction, set...

System.NotSupportedException
Implicit distributed transactions have not been enabled. If you're intentionally starting a distributed transaction, set TransactionManager.ImplicitDistributedTransactions to true.
   at System.Transactions.DtcProxyShim.DtcProxyShimFactory.ConnectToProxy(String nodeName, Guid resourceManagerIdentifier, Object managedIdentifier, Boolean& nodeNameMatches, Byte[]& whereabouts, ResourceManagerShim& resourceManagerShim)
   at System.Transactions.Oletx.DtcTransactionManager.Initialize()
   at System.Transactions.Oletx.DtcTransactionManager.get_ProxyShimFactory()
   at System.Transactions.TransactionInterop.GetOletxTransactionFromTransmitterPropagationToken(Byte[] propagationToken)
   at System.Transactions.TransactionStatePSPEOperation.PSPEPromote(InternalTransaction tx)
   at System.Transactions.TransactionStateDelegatedBase.EnterState(InternalTransaction tx)
   at System.Transactions.EnlistableStates.Promote(InternalTransaction tx)
   at System.Transactions.Transaction.Promote()
   at System.Transactions.TransactionInterop.GetExportCookie(Transaction transaction, Byte[] whereabouts)
   at Microsoft.Data.SqlClient.SqlInternalConnection.GetTransactionCookie(Transaction transaction, Byte[] whereAbouts)
   at Microsoft.Data.SqlClient.SqlInternalConnection.EnlistNonNull(Transaction tx)
   at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.PrepareConnection(DbConnection owningObject, DbConnectionInternal obj, Transaction transaction)
   at Microsoft.Data.SqlClient.ConnectionPool.WaitHandleDbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
   at Microsoft.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
   at Microsoft.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry, SqlConnectionOverrides overrides)
   at Microsoft.Data.SqlClient.SqlConnection.InternalOpenAsync(SqlConnectionOverrides overrides, CancellationToken cancellationToken)
--- End of stack trace from previous location ---
   at Dapper.SqlMapper.QueryMultipleAsync(IDbConnection cnn, CommandDefinition command) in /_/Dapper/SqlMapper.Async.cs:line 1040

Verbose output

EF Core version

10.0.0-rc.1.25451.107

Database provider

No response

Target framework

10.0.0-rc.1.25451.107

Operating system

No response

IDE

No response

[roji]

I'm assuming that the upgrade from EF9 to EF10 brings in a new version of SqlClient, and that's the source of the issue. Try leaving the EF version and manually bumping the SqlClient version (to the latest 6.1.1) and you should be able to repro the same problem. At that point you can report this issue on the SqlClient repo.

I Cannot provide the source code for confidentiality reasons

Regardless of where the problem is - EF or SqlClient - you will be required to provide a minimal repro. Nobody is asking you to provide confidential company code, but rather to narrow down the problem to a minimal console program that does not contain any confidential code but reproduces the problem. Otherwise, if you just post "I have an error" without any code, it's quite unlikely anyone would be able to investigate and help.

[dde-inx]

Thanks for you answer, really appreciated.
It is working fine with SqlClient 6.1.1, Ef 9.0.9 and Dapper 2.1.66.
I will do that minimal program.
Thanks again !

[dde-inx]

Please find attached a solution with 2 projects:

• Ef10DapperFails
• Ef9DapperWorks
  Only difference between the 2 projects is the version of EF (10-rc.1 vs 9.0.9).

ReproEfDapperTransaction.zip

Please check the README.md for repro steps.

Thanks for the support.

[roji]

@dde-inx thanks for minimal repro - that's exactly what we needed, and thanks to it I can confirm the behavioral change from 9 to 10: see minimal repro below.

Minimal repro

await using (var context = new MyDbContext())
{
    await context.Database.EnsureDeletedAsync();
    await context.Database.EnsureCreatedAsync();
}

using (var scope = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
    await using (var context = new MyDbContext())
    {
        _ = await context.Blogs.FirstOrDefaultAsync();
    }

    await using (var connection = new SqlConnection(MyDbContext.ConnectionString))
    await using (var command = connection.CreateCommand())
    {
        await connection.OpenAsync();

        command.CommandText = "SELECT 1";
        var result = await command.ExecuteScalarAsync();
    }

    scope.Complete();
}

public class MyDbContext : DbContext
{
    public const string ConnectionString = "Server=localhost;Database=test;User=SA;Password=Abcd5678;Connect Timeout=60;ConnectRetryCount=0;Encrypt=false";

    public DbSet<Blog> Blogs { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
        => optionsBuilder
            .UseSqlServer(ConnectionString)
            .LogTo(Console.WriteLine, LogLevel.Information)
            .EnableSensitiveDataLogging();
}

public class Blog
{
    public int Id { get; set; }
    public string Name { get; set; }
}

The source of the change is #36548. In EF10 we started adding Application Name to the connection string to identify EF, SqlClient and their versions for telemetry purposes (this is #35730). When using the same connection string from within EF and from outside (e.g. Dapper), EF now injects the Application Name, but Dapper leaves the connection string as-is. SqlClient, when checking whether a connection can be reused within a TransactionScope (in which case distributed transactions aren't necessary), simply compares connection strings, and any change causes it to open a new connection instead, triggering escalating to a distributed transaction.

At least as a workaround, simply add any Application Name into your connection string: when EF sees that the user has set one, it does not override it, leaving the connection string untouched. At the very least this merits a breaking change note for EF10 - I'll discuss with the team that we're OK with this otherwise (I think we should be).

[dde-inx]

Thanks Shay for the explanation and the workaround !

[roji]

Design discussion: we're OK with the new behavior and will document this as a breaking change.