Move AAD/Entra Authentication into new Azure package

[paulmedynski]

Overview

This PR contains changes to move the ActiveDirectoryAuthenticationProvider out of the MDS package and into the new Azure package. Please refer to the design here:

MDS Azure Extension Design

This PR is only concerned with moving the provider code out of MDS and creating the necessary base classes and types in the Abstractions package, which includes:

• Creation of base classes/types in Abstractions related to the SQL authentication provider APIs.
• Move of the ActiveDirectoryAuthenticationProvider.cs file into the Azure package.
• Creation of the Azure package and related PR/CI pipelines.
• Targeted updates/improvements due to blast radius/fallout of the above.

Future PRs will address:

• Proper documentation (API, samples, reference).
• Dependency updates.
• Terminology modernization.
• String localization.
• Code refactoring/improvements.
• Addition of a synchronous AcquireToken() method.
• Separation of existing tests out of the MDS project and into the Azure project.
• Addition of unit tests and improved integration tests.
• New tests in the MDS project to confirm the authentication provider management logic.
• Any additional issues we come up with that aren't directly related to the move.

This builds on the previous 2 PRs:

• Abstractions Package - C# project changes #3626
• Abstractions Package - Pipeline Changes #3628

Testing

All existing tests in the MDS project are passing. This confirms that the move didn't break anything that is currently being tested.

[paulmedynski]

Commentary for reviewers and some TODOs for me.

[paulmedynski]

Commentary for reviewers.

[codecov]

Codecov Report

❌ Patch coverage is 77.77778% with 54 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (feat/azure-split@287309f). Learn more about missing BASE report.

Files with missing lines	Patch %	Lines
...Data/SqlClient/SqlAuthenticationProviderManager.cs	78.72%	20 Missing ⚠️
...crosoft/Data/SqlClient/SqlInternalConnectionTds.cs	61.76%	13 Missing ⚠️
...crosoft/Data/SqlClient/SqlInternalConnectionTds.cs	61.76%	13 Missing ⚠️
...ta/SqlClient/SqlAuthenticationParametersBuilder.cs	79.41%	7 Missing ⚠️
...Microsoft/Data/SqlClient/TdsParserHelperClasses.cs	95.45%	1 Missing ⚠️

Additional details and impacted files

@@                 Coverage Diff                 @@
##             feat/azure-split    #3680   +/-   ##
===================================================
  Coverage                    ?   76.78%           
===================================================
  Files                       ?      269           
  Lines                       ?    45029           
  Branches                    ?        0           
===================================================
  Hits                        ?    34574           
  Misses                      ?    10455           
  Partials                    ?        0           

Flag	Coverage Δ
addons	90.82% <ø> (?)
netcore	76.63% <75.11%> (?)
netfx	76.14% <80.38%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[paulmedynski]

Commentary for reviewers, and a few things for me to fix.

[David-Engel]

Partial 45/89 review

[paulmedynski]

I reverted all of the previous public API changes and left notes about what we may want to bring back in the future.

[apoorvdeshmukh]

Do we need any updates to the samples such as doc/samples/AADAuthenticationCustomDeviceFlowCallback.cs and doc/samples/ApplicationClientIdAzureAuthenticationProvider.cs?

[paulmedynski]

Perhaps - all documentation activities are deferred to future PRs.

[cheenamalhotra]

Minor comments, generally we can take it forward and address remaining work in future PRs.

[cheenamalhotra]

Are you planning to use common variables for target frameworks as done in MDS tests in another PR?

[paulmedynski]

That sounds like a great idea after the .NET and .NET Framework MDS projects merge, and we have the same set of target frameworks for all of our projects.

[cheenamalhotra]

I see you removed the packages.props in above directory.. What version will be picked up here?

[paulmedynski]

MSBuild walks up the directory tree until it finds a Directory.Packages.props file, so this project will find this props file:

src/Directory.Packages.props

That's the same one everything else in the src directory uses. It specifies the MDS package version as:

    <PackageVersion
      Include="Microsoft.Data.SqlClient"
      Version="$(MdsPackageVersion)" />

The $(MdsPackageVersion) is explicitly set by all pipelines, so it's either a CI/PR build number, or the official values found in YAML or ADO Libraries. For command-line/IDE builds, we use a default value chosen by Version.props:

    <MdsPackageVersion Condition="'$(MdsPackageVersion)' == ''">$(MdsVersionDefault).$(BuildNumber)-dev</MdsPackageVersion>

[benrr101]

Overall I'm only really complaining about the structure tests to make it clearer with less words. But I will accept things like "oh we'll fix those later"

[benrr101]

Please make sure that this is accurate for the file path and the namespaces of the files. Some IDEs will complain if the namespaces don't match the path, and I agree with that preference. That's why a while back I made a change to remove the root namespace from MDS projects (since the paths replicate the full namespace, and contain things outside the MDS namespace).

[benrr101]

Calling back to the root namespace comment, since this is in the Microsoft.Data.SqlClient namespace, this will raise a warning in some IDEs. Since the root namesapce is Microsoft.Data.SqlClient.Extensions.Abstractions, the expected namespace for this class would be Microsoft.Data.SqlClient.Extensions.Abstractions. But, since this is a public API, we can't change the namespace without it being a breaking change. Soooo, I'd recommend making the root namespace either blank (and putting the files in a Microsoft.Data.SqlClient folder) or making the root namespace Microsoft.Data.SqlClient (and all abstraction files in an Extensions.Abstractions folder)

[paulmedynski]

Let's defer project directory structure discussions/changes until after the MDS project merge. We already have a mishmash of approaches and we need to do a full sweep anyway.

[benrr101]

Introducing aliases for "Entra*" might be a good idea at ... some point.

[paulmedynski]

Agreed, but not today :)

[benrr101]

This will cause some grumbling from some IDEs... but I can't think of a good alternative that doesn't inject our internal comments into public docs.

[paulmedynski]

Shrug - I can't imagine why an IDE would grumble about XML and normal comments appearing together. They serve different purposes.

[benrr101]

Constructors then properties :)

[paulmedynski]

I avoided style changes like this on purpose to make diffs to the originals sane.

[benrr101]

Nit: for constants like null, it would be very nice to use the argument label

[benrr101]

If you want to add comment blocks to test files, I won't complain, but please use xmldocs

[benrr101]

I'm gonna sound like a broken, pedantic but this is why it's important to layout the stages of a test, and use descriptive names for the tests. At first glance, I'd assume this test verifies that a provider can be gotten successfully. And at second glance, I'd assume that there's actually two test cases in here.

So, I'd recommend rewriting as

[Fact]
public void GetProvider_MdsMissing_ReturnsNull()
{
   // Precondition
   // - Ensure MDS really doesn't exist in the working path
   Assert.Throws<FileNotFoundException>(() => Assembly.Load("Microsoft.Data.SqlClient"));

   // Act
   var result = SqlAuthenticationProvider.GetProvider(SqlAuthenticationMethod.ActiveDirectoryInteractive);

   // Assert
   Assert.Null(result);
}

And with these changes, we know at a glance:

• What the test does (without resorting to reading comments - or writing them!)
• Which part is a pre-condition of the test passing
• Which part is the action
• Which part is the validation

I know it's more total lines, but it really does help make it easier to figure out tests at-a-glance. And considering most tests will sit for a loooong time without being looked at, we want future generations to have the easiest time understanding unit tests as possible.

[paulmedynski]

I'll move the precondition out into a constructor.

IMO, introducing variables just to follow a pattern is a recipe for a botched test. There are certainly conditions where you need to do a few things and then check state or results. This isn't one of those cases though.

[benrr101]

I'd still personally prefer it if test projects go in the root /test/ rather than under the project. But, we can argue about that later.

[paulmedynski]

We definitely need a consistent approach - TBD!

[benrr101]

oof, yeah we're gonna have to argue about this

[paulmedynski]

That's the result of:

$ cd src
$ dotnet sln add Microsoft.Data.SqlClient.Extensions/Azure/src/Azure.csproj
$ dotnet sln add Microsoft.Data.SqlClient.Extensions/Azure/test/Azure.Test.csproj

I assume dotnet knows what it's doing.