Feature | Add support for user-defined ApplicationClientId

[cheenamalhotra]

The PR enables support for passing "Application Client Id" to the MSAL library via driver for fetching access tokens in order to perform Active Directory authentication. In order to support the same, below new APIs are introduced:

1. A new constructor has been introduced in ActiveDirectoryAuthenticationProvider
   [Applies to all .NET Platforms (.NET Framework, .NET Core and .NET Standard)]

public ActiveDirectoryAuthenticationProvider(string applicationClientId)

Usage:

string APP_CLIENT_ID = "<GUID>";
SqlAuthenticationProvider customAuthProvider = new ActiveDirectoryAuthenticationProvider(APP_CLIENT_ID);
SqlAuthenticationProvider.SetProvider(SqlAuthenticationMethod.ActiveDirectoryInteractive, customAuthProvider);

using (SqlConnection sqlConnection = new SqlConnection("<connection_string>")
{
    sqlConnection.Open();
}

2. A new configuration property has been introduced under SqlAuthenticationProviderConfigurationSection and SqlClientAuthenticationProviderConfigurationSection
   [Applies to .NET Framework and .NET Core]

internal class SqlAuthenticationProviderConfigurationSection : ConfigurationSection
{
    ...
    [ConfigurationProperty("applicationClientId", IsRequired = false)]
    public string ApplicationClientId => this["applicationClientId"] as string;
}

// Inheritance
internal class SqlClientAuthenticationProviderConfigurationSection : SqlAuthenticationProviderConfigurationSection 
{ ... }

Usage:

<configuration>
  <configSections>
    <section name="SqlClientAuthenticationProviders"
             type="Microsoft.Data.SqlClient.SqlClientAuthenticationProviderConfigurationSection, Microsoft.Data.SqlClient" />
  </configSections>
  <SqlClientAuthenticationProviders applicationClientId ="<GUID>" />
</configuration>

<!--or-->

<configuration>
  <configSections>
    <section name="SqlAuthenticationProviders"
             type="Microsoft.Data.SqlClient.SqlAuthenticationProviderConfigurationSection, Microsoft.Data.SqlClient" />
  </configSections>
  <SqlAuthenticationProviders applicationClientId ="<GUID>" />
</configuration>

cc @David-Engel @shueybubbles

[shueybubbles]

I am curious to know whether you've found the current code structure, with separate .cs files for the various target platforms, and separate skeleton DLLs under /ref, to be truly sustainable.
I perceive it as requiring a lot of duplicate coding with a high risk of bugs showing up in one platform and not the other.
For SMO I took the approach of using inline '#if' directives to fork code based on the target platform, and the DLLs under /lib in the nuget package are what clients use for reference as well.
What advantages did you get with the separate CS files that I am missing?

[cheenamalhotra]

Hi @shueybubbles

The reason we have separate code base is because they came from different sources when the code was imported and there were a lot of new features coming in .NET Core codebase, which pushed merge activity to lower priority... We're trying to integrate it to common location, but it is a big activity and does require a dedicated time. Also our NetFx project file (csproj) is not both based on "Microsoft.Net.Sdk" right now, it's based on old MsBuild architecture.

It may be possible to resolve all these differences, but effort is not prioritized yet.
It does cause a lot of duplicated effort, indeed.

Regarding cs file differences for different platforms, I think we have a mix and match. Most of the times for large files, we've been using separate files and including them for specific platform in csproj.

[JRahnama]

LGTM, the only thing is about the static constructor. Can we have a more specific message stating the static constructor has caught the exception? Since the static members are made before all other members it is sometimes difficult debugging/troubleshooting the source of the issues they cause.