Cannot load SNI dll

[mdaigle]

Describe the bug

When I try to use the driver, the SNI dll doesn't load!

Expected behavior

The dll loads and the driver works.

Further technical details

Microsoft.Data.SqlClient version: 7.0.0
.NET target: .NET 10
SQL Server version: Azure SQL
Operating system: Docker container

[github-actions]

🔍 Triage Summary

Check	Result
Issue type	Bug
Environment	⚠️ Missing: repro steps (no explicit steps to reproduce), full error message / stack trace
Area	Area\Native SNI
Duplicates	Potentially related: Unable to load DLL Microsoft.Data.SqlClient.SNI.x64.dll — similar Native SNI DLL load failures have been reported previously
Regression	Not indicated

Analysis

The reporter is encountering a failure to load the SNI DLL when running Microsoft.Data.SqlClient 7.0.0 on .NET 10 inside a Docker container targeting Azure SQL. The "SNI dll doesn't load" error points to the Native SNI layer (Microsoft.Data.SqlClient.SNI.runtime), which can fail to load in Linux-based Docker containers if the correct native runtime package is missing, the architecture is mismatched (e.g., ARM64 vs x64), or the required native OS dependencies (e.g., libssl, libkrb5) are absent. This is a P2 issue — it blocks connectivity entirely but likely has a known workaround (using Managed SNI or adding missing dependencies). Note that .NET 10 is not yet a shipped TFM for this package (currently test/runtime-only), which may also contribute to the problem.

Next Steps

• @mdaigle, please provide the following missing details so we can investigate further:

  1. Full error message and stack trace — copy the exact exception text (e.g., Unable to load DLL 'Microsoft.Data.SqlClient.SNI.x64.dll' or a platform-not-supported error)
  2. Repro steps — a minimal Dockerfile or sequence of commands that reproduces the issue
  3. Docker base image — e.g., mcr.microsoft.com/dotnet/runtime:10.0, ubuntu:22.04, alpine, etc. (Alpine-based images are a common cause of SNI load failures due to missing glibc)
  4. CPU architecture — x64, ARM64, or other?

• In the meantime, consider trying Managed SNI as a workaround by setting the AppContext switch before opening any connection:

  AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseManagedNetworkingOnWindows", true);

  Or on Linux, Managed SNI is used by default — if it is still failing, the Docker base image likely lacks libssl or libkrb5.

Generated by SqlClient Issue Auto-Triage for issue #29 · ● 315.2K · ◷