Open deadlydog opened 2 weeks ago
I've created PR #2975 to mention the backward incompatibility in the docs for now, but it would still be nice to have SqlConnectionStringBuilder
use the backward-compatible keywords by default.
@David-Engel Looking for your input on this.
Is your feature request related to a problem? Please describe.
Connection strings returned from the
SqlConnectionStringBuilder
are not always compatible withSystem.Data.SqlClient
connection strings, even when they are using features supported by both. This is because theMicrosoft.Data.SqlClient
connection string introduced new aliases that are not supported by theSystem.Data.SqlClient
connection string, such asApplication Intent=
instead ofApplicationIntent=
(notice the space). There are many other keywords updated to include spaces thatSystem.Data.SqlClient
does not support.This problem likely won't affect most apps, however, there are some scenarios where it will. For us, it affected our service-discovery service that other applications talk to in order to get the connection string they should use. Some of those other applications are still using
System.Data.SqlClient
, and thus the connection string returned by our service-discovery service was now invalid for those apps; they were receiving connection strings withApplication Intent=ReadOnly
in them instead ofApplicationIntent=ReadOnly
, which is unsupported inSystem.Data.SqlClient
.When trying to use a
Microsoft.Data.SqlClient
connection string in an app connecting usingSystem.Data.SqlClient
, we received the following error:Describe the solution you'd like
It would be good if the
SqlConnectionStringBuilder
's.ConnectionString
property used the backward compatible keywords, where applicable. For example, instead of returning a connection string withApplication Intent=
orMulti Subnet Failover=
in it, it usedApplicationIntent=
andMultiSubnetFailover=
instead.Describe alternatives you've considered
For now we've updated our service-discovery service to manually sanitize the connection string to use the backward compatible keywords, rather than just returning back the
SqlConnectionStringBuilder.ConnectionString
directly.For this repo, if you choose to leave things as-is, we should at least add some documentation for this backward incompatibility.
Additional context
The new connection string format is a breaking change from
System.Data.SqlClient
. This seems like an easy way to restore backward compatibility.