[API Proposal] Expose SqlConnection.IsAzureDb

Provisioning and/or runtime logic may depend on whether a specified SqlClient DataSource is traditional MSSQL or AzureDb. The aim of this proposal is to expose the existing function for public consumption.

Rationale and Usage

This can be done in custom code by emulating the same logic as the ADP class, however that approach is fragile should (say) Azure open another endpoint (as happened with database.chinacloudapi.cn and secure.windows.net).

Here’s an example callsite where we’d harden a user-supplied connection string (app.config) for SqlAzure. Today we do this via the emulation described above.

SqlConnectionStringBuilder sqlCsb = …; // Load from app.config
if (sqlCsb.IsAzureDb)
{
    sqlCsb.TrustServerCertificate = false;
    sqlCsb.Encrypt = true;
    … // Different security, retry policy, timeouts, etc
}

Proposed API

// Existing: src/System.Data.SqlClient/src/System/Data/Common/AdapterUtil.SqlClient.cs
namespace System.Data.Common
{
    internal static partial class ADP
    {
        // Code compares DataSource against a set of (internally) well-known endpoints
        internal static bool IsAzureSqlServerEndpoint(string dataSource) { … }
    }
}

// Suggested public api
public sealed class SqlConnectionStringBuilder
{
    public bool IsAzureDb => ADP.IsAzureSqlServerEndpoint(this.DataSource);
}

// and/or
public sealed class SqlConnection
{
    public bool IsAzureDb => ADP.IsAzureSqlServerEndpoint(this.DataSource);
}

Details

• This would appear to be low-risk, since the functionality already exists and is leveraged by SqlClient.
• The internal method may need to be hardened against nulls, casing, etc

Questions

• Not sure what the best name for this property would be; IsAzureSql, IsAzure, IsAzureDb, IsAzureDataSource, IsAzureEndpoint
• Not sure whether to expose this property on one or both classes
• Not sure whether it should be a concrete property on the class(es) or rather extension method(s)

[David-Engel]

We can’t guarantee that it always returns the correct value. And it could change over time. Right now those functions are used in places that continue to work if the method returns the wrong result. If you want to code a function into your app that does the same thing, SqlClient currently looks for the following endsWith in the datasource:

.database.chinacloudapi.cn .database.windows.net .database.cloudapi.de .database.usgovcloudapi.net

[karelz]

I am a fairly new contributor so I do not have a strong grasp of how features are ushered through the process.

Understood. Just trying to set expectations 😃 … the API process is a bit slow by design (think weeks at minimum). Some areas have much longer backlogs 😦 (think months/years) and therefore have to prioritize heavily based on usefulness compared to other APIs/features in the area. You can see the API process details here: https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/api-review-process.md

since it is already used internally, its utility as a public api is worth consideration.

It is worth consideration, it does not mean it has to be prioritized though.

may be useful more generally than my own supportive use case. Lift & shift comes to mind.

I’ll leave it to area experts to comment on that. If there is good scenario, it would make sense …