still problems with Microsoft.Data.SqlClient versions?

[devployment]

is this article and the mentioned versions still relevant?

https://duendesoftware.com/blog/20250506-microsoft-azure-sql-and-entity-framework-core-performance-issues-and-solution

or is this safe these days

    <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="10.0.7" />
    <PackageReference Include="Microsoft.Data.SqlClient" Version="7.0.1" />

[khalidabuhakmeh]

@devployment, we haven't received any reports of issues after teams have upgraded to the known fixed packages in the blog post.

[devployment]

so that means everything above the last entry in the blog post should be fine?

Just don't want to run into some unexpected issue related to this as I'm doing quite some upgrade.

[khalidabuhakmeh]

It's been a while since I wrote the post, but that is Correct. If you do run into any issues, please let us know.

[GustaveCG]

Hello @khalidabuhakmeh @devployment ,

We are currently planning to migrate our Duende IdentityServer 7.4.x solution to .NET 10 (Duende 8.0.4 ) , Entity Framework Core 10, and Microsoft.Data.SqlClient 7.0.2.

While evaluating the migration, we reviewed your article:

Microsoft Azure SQL and Entity Framework Core performance issues and solution (https://duendesoftware.com/blog/20250506-microsoft-azure-sql-and-entity-framework-core-performance-issues-and-solution )

In that article, you recommend using Microsoft.Data.SqlClient 5.2.2 due to the driver's automatic connection retry behavior, which could cause significant performance degradation.

However, while reviewing Microsoft's documentation for Microsoft.Data.SqlClient 7.x, we found that a new overload was introduced for SqlConnection.OpenAsync() that allows applications to explicitly disable the driver's internal retry logic:

await sqlConnection.OpenAsync(
    SqlConnectionOverrides.OpenWithoutRetry,
    cancellationToken);

SqlConnectionOverrides.OpenWithoutRetry, cancellationToken

Microsoft documents this feature as follows:

Support for connection invalidations was added to the OpenAsync() API. The default behavior of SqlConnection.OpenAsync() can be overridden to disable the ten-second delay and automatic connection retries triggered by transient errors.

Because of this, we have a few questions regarding the recommendations in your article.

Our questions

1. Have you recently validated Duende IdentityServer 8.x with Microsoft.Data.SqlClient 7.x?
2. Does your recommendation to remain on Microsoft.Data.SqlClient 5.2.2 still apply, or do you consider SqlClient 7.x to have resolved the issue described in your article?
3. Regarding Entity Framework Core 10, do you know whether EF Core internally takes advantage of SqlConnection.OpenAsync(SqlConnectionOverrides.OpenWithoutRetry, CancellationToken), or does it still call the traditional DbConnection.OpenAsync(CancellationToken) overload?
4. If EF Core still uses the traditional overload, do you believe there is any remaining performance concern for applications based on Duende IdentityServer?
5. Finally, do you have any recommendations or known considerations when running Duende IdentityServer 8.x with .NET 10, EF Core 10, and Microsoft.Data.SqlClient 7.x on managed SQL Server platforms such as Azure SQL or Cloud SQL for SQL Server?

We appreciate any guidance you can provide, as we would like to ensure we are following the recommended approach before proceeding with our migration.

[khalidabuhakmeh]

Hello @GustaveCG @devployment,

Since writing that post, I believe the issue has been resolved. I have not heard from any customers experiencing the same issues on the lastest versions of the SqlClient, EF Core 10, or .NET 10. From memory, the fix was also being ported and has likely made it into the package.

The performance degredation is based on failed connections or under-provisioned database servers. A healthy production environment should not have any of these issues, but always test in staging before deploying changes.

My understanding is the retry logic is enabled by default, and I would keep it enabled since a slow successful request is better than a failure for users.

For managed databases in a cloud environment, always run a load test to determine if you are scaled appropriately. Under provisioning can be a big headache, so do proper tests here based on your needs.

TL;DR: You should be good to go, but reach out if you're experiencing any issues and we're happy to help with any questions. Remember, test, test, test; All environments are unique, and yours is no different.

Cheers 👍🙌😁