SqlClient 7.1.0 Fixes IPv6 Named Pipes Reboots on .NET 8/9

Microsoft’s GitHub release record dates the GA release to September 18 and identifies application identity reporting, connection and transaction fixes, and the deprecation of TransparentNetworkIPResolution as headline changes. Its practical significance is more specific than a promise of improved performance: several fixes address what happens after a transaction fails, a connection breaks, or a reader starts streaming data.

Microsoft.Data.SqlClient 7.1.0 repairs the paths around failed connections​

Connection pooling allows applications to reuse database connections instead of starting from scratch for every operation. Microsoft’s announcement describes several cases where maintaining that pool could go wrong, including broken connections returning to circulation, misleading performance counters, and unnecessary background activity.

The most instructive correction concerns TransactionScope rollback. Microsoft’s release notes describe a pooled connection returning in a broken state after rollback—for example, when promotion to a distributed transaction fails on.NET 8 or later, where implicit distributed transactions are disabled by default. A subsequent Open() could succeed, only for BeginTransaction() to throw InvalidOperationException with “the connection has been broken.”

That sequence explains why a simple connectivity check would be insufficient to validate this fix. Opening the connection was already capable of succeeding; the failure appeared when the application tried to use it for another transaction. Microsoft says connection reset now preserves the transaction when the pooled connection is either a delegated transaction root or enlisted in a transaction, rather than checking only the latter condition.

For an application that uses TransactionScope, a useful regression test therefore follows the whole affected sequence: exercise the rollback condition in a representative test environment, obtain another pooled connection, and attempt the subsequent transaction. That recommendation follows directly from the documented failure, rather than assuming that any successful query proves the pool is healthy.

Other fixes address the surrounding bookkeeping. According to Microsoft’s announcement, pool performance counters could become negative or drift upward after failed or broken connections. A connection-factory timer could also continue waking the process when no pools required maintenance. The preview release notes included in Microsoft’s release history identify the latter behavior as a wake-up every 30 seconds, including when pooling was disabled or after ClearAllPools().

These changes give operators two different benefits: more accurate pool diagnostics and less unnecessary background work. Neither establishes a measured throughput increase. Microsoft has not supplied a workload benchmark for these corrections in the announcement, so “more predictable failure handling” is the defensible expectation.

The announcement also reports a connection-opening race that could produce InvalidCastException, invalid parser state in failover login paths, and cancellation-token sources that remained allocated longer than necessary. Long-running services and applications that reconnect frequently are sensible priorities for evaluation because they repeatedly exercise these paths; that is a deployment priority inferred from the fixes, not a claim that every such application has encountered them.

The Named Pipes correction has a narrow but consequential Windows scope​

Microsoft’s GA release notes document another reliability fix involving IPv6 literal server names over Named Pipes in managed SNI, the provider’s managed SQL Server Network Interface implementation. The affected code could construct a malformed UNC pipe path containing a colon in its host component. Microsoft says passing that path to Windows could trigger an access violation inside LSASS and force a reboot.

The correction converts valid IPv6 literals to their .ipv6-literal.net representation. A colon-bearing host that cannot be interpreted as valid IPv6 now fails with the standard invalid-connection-string error instead.

The release notes scope this managed-SNI correction to the net8.0 and net9.0 targets. Colon-free hostnames, LocalDB, localhost, ., and IPv6 connections over TCP are explicitly unaffected. Teams using this particular Named Pipes configuration have a stronger reason to prioritize testing, but the evidence does not justify describing all SqlClient connections as vulnerable to a Windows restart.

SqlClient 7.1.0 fixes type handling without changing the database engine​

Several corrections concern the provider’s interpretation or transmission of data. They matter because a valid application value can still fail if the client represents it using the wrong SQL type, or if discovery code incorrectly concludes that the server lacks a capability.

Microsoft’s announcement identifies these changes:

The decimal fix deserves particular attention in Always Encrypted applications. Microsoft notes that these workloads commonly specify precision and scale explicitly, placing them directly within the described scenario. The supported conclusion is a correction to parameter handling, not a change to encryption strength or a blanket guarantee that every decimal overflow has been eliminated.

The DateOnly fix likewise has a defined boundary: variants and table-valued parameters. Tests should retain the application’s actual parameter representation and date values. Replacing the affected case with a simpler date parameter would not exercise the same behavior.

Azure SQL JSON discovery now checks capability instead of a version string​

The JSON discovery correction provides a concrete explanation of how a seemingly reasonable version check can fail across SQL Server and Azure SQL.

Microsoft’s release notes say the old code filtered the json row using a string comparison against a minimum server version of 17.00.000.0. Azure SQL reports a 12.00.xxxx server version, so that check could never succeed there. The underlying service could support the type while the provider’s discovery result omitted it.

SqlClient 7.1.0 instead uses the JSON support flag negotiated through the TDS FEATUREEXTACK token. TDS, or Tabular Data Stream, is the database communication protocol handled by the provider. In this case, the negotiated capability supplies the answer that a comparison of server-version strings could not.

Applications and tools can continue using the same call:

connection.GetSchema("DataTypes");

The corrected result concerns discovery of an available type. Installing SqlClient 7.1.0 does not, by itself, add JSON support to a database engine that lacks it.

For teams that generate data-access behavior from schema information, this is a useful validation target: confirm that a JSON-capable Azure SQL database now exposes the expected type through discovery. For streaming readers, the corresponding test should preserve the documented order—IsDBNull() followed by the streamed read—and check the returned content, rather than merely checking that no exception occurs.

RegisteredApplication makes SqlClient telemetry more useful—with pooling limits​

SqlClient 7.1.0 adds a RegisteredApplication enum and a matching SqlConnection.RegisteredApplication property. Microsoft’s release notes explain that libraries and tools can use these to identify themselves in version 2 of the TDS USERAGENT feature extension.

The intended users include Entity Framework Core, SQL Server Management Studio, SqlPackage, Semantic Kernel, and Data API Builder. These are examples of client stacks that can register an identity, not evidence that every released version of those products already does so.

Microsoft’s documented usage sets the property before opening the connection:

using Microsoft.Data.SqlClient;

using var connection = new SqlConnection(connectionString);

connection.RegisteredApplication =
    RegisteredApplication.EntityFrameworkCore;

await connection.OpenAsync();

This example is intended for the appropriate library or integration layer. Ordinary applications generally do not need to identify themselves as Entity Framework Core or set the property at all. Microsoft says assigning it while the connection is connecting or open throws InvalidOperationException.

The before-and-after distinction is straightforward. Version 1 of the USERAGENT payload carried no application identifier; version 2 always emits one. A newly created physical connection with no registered value reports Unknown, or zero.

There is an important limit for anyone interpreting the resulting telemetry: the application identity is not part of the connection pool key. Microsoft says a pooled physical connection reports the application that originally created it, while background connections created to satisfy Min Pool Size report Unknown. Cloned connections preserve the property.

Consequently, an operator should not interpret the field as a fresh, authenticated identity for every logical use of a pooled connection. It describes the registered client stack associated with creation of that physical connection. This makes it useful for workload diagnosis while limiting the conclusions that can safely be drawn from it.

The release also adds a driver-owned, 64-bit Driver Properties field, whose bit zero indicates whether Connection Pool V2 is enabled for the process. Reporting that state is not the same as enabling the alternative pool.

Most importantly, Microsoft explicitly says RegisteredApplication must never be used for authorization or other security decisions. It is client-supplied telemetry. Its usefulness is in separating client stacks during investigation, not in proving that a connection deserves access to a database.

TransparentNetworkIPResolution becomes obsolete without a runtime switch​

The deprecation in 7.1.0 affects SqlConnectionStringBuilder.TransparentNetworkIPResolution. Microsoft marks the property obsolete and directs callers toward MultiSubnetFailover, which addresses the same goal of connecting quickly across multiple DNS-resolved addresses and is the documented approach for Always On availability-group listeners.

The framework boundary matters here. Microsoft’s release notes identify Transparent Network IP Resolution, or TNIR, as a.NET Framework-only feature. The property is not exposed on modern.NET, where a connection string containing the Transparent Network IP Resolution keyword still throws NotSupportedException.

For.NET Framework applications referencing the property, the new visible effect is a CS0618 compiler warning. There is no runtime behavior change in 7.1.0: TNIR still defaults to true on.NET Framework, and MultiSubnetFailover still defaults to false.

That means upgrading the provider and changing connection settings are separate decisions. A team can evaluate the reliability fixes without simultaneously changing its failover configuration. If it chooses to migrate to MultiSubnetFailover, it should validate that change against its actual listener and connection behavior rather than treating the compiler warning as an instruction to edit production settings immediately.

Microsoft says changing the TNIR and MultiSubnetFailover defaults is deferred to a future major version. No date is established in the release record. For now, the actionable development is a source-level warning and a migration direction, not an automatic connection-policy change.

Upgrading SqlClient 7.1.0 means aligning the packages you use​

Microsoft’s NuGet package description identifies.NET Framework 4.6.2 and later and.NET 8.0 and later as supported platforms. The package also includes a.NET Standard 2.0 target; its broader computed compatibility entries should not be mistaken for a promise of support for every runtime listed by NuGet.

For a project that directly manages its SqlClient dependency through the.NET CLI, the documented installation command is:

dotnet add package Microsoft.Data.SqlClient --version 7.1.0

The base provider is only part of the dependency check. Microsoft’s GitHub release notes say the aligned package set continues the versioning policy introduced with 7.0.2:

• Microsoft.Data.SqlClient ships as version 7.1.0.
• Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider ships as version 7.1.0.
• Microsoft.Data.SqlClient.Extensions.Azure ships as version 7.1.0.
• Microsoft.Data.SqlClient.Extensions.Abstractions ships as version 7.1.0.
• Microsoft.Data.SqlClient.Internal.Logging ships as version 7.1.0.

Update the companion packages the application references; the list is not a requirement to add unused integrations. Microsoft.SqlServer.Server remains independently versioned at 1.0.0.

The Azure extension is particularly important when crossing into the 7.x line from an older provider. Microsoft’s package documentation says that, starting with 7.0, Entra ID authentication modes selected through connection-string keywords require Microsoft.Data.SqlClient.Extensions.Azure. Examples include Active Directory Default, Active Directory Managed Identity, and Active Directory Interactive.

That prerequisite is an existing 7.0 architectural boundary, not a new 7.1 authentication change. Nevertheless, a team jumping directly from an earlier major version needs to account for it. Teams already using the extension must align it with the 7.1.0 provider.

The binding-redirect assurance applies to specific starting versions​

Microsoft says the aligned assemblies have FileVersion 7.1.0.x while retaining AssemblyVersion 7.0.0.0. Consequently, upgrades from 7.0.2, 7.0.3, or any 7.1 preview do not require new.NET Framework strong-name binding redirects.

Do not broaden that assurance to every previous release. Microsoft notes that Extensions.Azure, Extensions.Abstractions, and Internal.Logging changed their assembly version from 1.0.0.0 to 7.0.0.0 in 7.0.2. Applications coming from 7.0.0 or 7.0.1 therefore cross an additional assembly-version boundary.

A focused upgrade sequence is to update the provider and referenced aligned packages, restore dependencies, build while reviewing warnings, and validate the application’s database paths in a representative environment. A successful build establishes neither correct failover behavior nor correct streamed output; those require exercising the affected operations.

What this means for your SqlClient deployment​

Prioritize 7.1.0 evaluation when your application uses the failure paths or data representations covered by the fixes. For applications without a matching symptom, the evidence supports a planned dependency update rather than an emergency rollout; Microsoft’s announcement does not establish a universal upgrade deadline.

• Test transaction reuse after rollback if the application uses TransactionScope; a successful Open() alone does not cover the documented broken-connection failure.
• Prioritize the managed-SNI Named Pipes correction if the application uses IPv6 literal server names on the affected net8.0 or net9.0 targets.
• Validate explicit decimal precision and scale, affected DateOnly parameters, Azure SQL JSON discovery, and null checks before streamed reads where those operations exist in your application.
• Keep referenced SqlClient companion packages at 7.1.0, especially Microsoft.Data.SqlClient.Extensions.Azure, and apply the binding-redirect assurance only to the documented starting versions.
• Treat RegisteredApplication as diagnostic metadata with physical-connection and pooling limits, never as an authorization signal.
• Review TNIR compiler warnings separately from the provider upgrade; 7.1.0 does not change its runtime defaults or make the keyword supported on modern.NET.

SqlClient 7.1.0 earns attention through concrete corrections to existing application behavior. The practical next step is an aligned package update backed by tests of rollback, reconnection, parameter handling, and streaming where those paths apply. That approach captures the release’s useful reliability work without conflating it with a database-engine upgrade, a new default pooling model, or an immediate failover-policy migration.