[DRAFT] Fix SupportsIntegratedSecurity Test Configuration

[paulmedynski]

Description

We have been skipping any tests that require Integrated Security. Our PR/CI pipelines appear to intend to use an Azure DevOps Library variable $(SupportsIntegratedSecurity), which is always true, but the tests still aren't running. This is because we use template expressions to convert the string library value to a YAML boolean parameter. But this doesn't work because the library variable $(SupportsIntegratedSecurity) isn't expanded at template expression evaluation time - it literally remains the string "$(SupportsIntegratedSecurity)".

I found all of the config properties that we're using as template expansion boolean values, and this was the only one using a runtime variable, so I just hardcoded them to true/false appropriately. I left a note in the YAML to help avoid this blunder in the future.

Testing

Normal PR and CI runs will show that the associated tests are no longer being skipped. One example is ADIntegratedUsingSSPI in the Manual Tests suite.

[Copilot]

Pull request overview

This draft PR investigates why Integrated Security tests are being skipped in the CI/CD pipeline. The author suspects that the Azure DevOps Library variable $(SupportsIntegratedSecurity) isn't being properly resolved, even though it should always be true. The PR hardcodes this value to true in the pipeline configuration to test whether this resolves the issue.

Changes:

• Hardcoded SupportsIntegratedSecurity: true in 6 test configurations that use local SQL Server instances (SQL 2019 x64, SQL 2019 x86, SQL 2022 x64, SQL 2022 x86, SQL 2022 named instance, and Always Encrypted tests)

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[paulmedynski]

Details of the failing tests:

• Failed Microsoft.Data.SqlClient.ManualTesting.Tests.LocalDBTest.LocalDbNamedPipeEncryptionNotSupportedTest [1 s]
• Failed Microsoft.Data.SqlClient.ManualTesting.Tests.LocalDBTest.SqlLocalDbNamedPipeConnectionTest [1 s]
• Failed Microsoft.Data.SqlClient.ManualTesting.Tests.LocalDBTest.LocalDbNamedPipeMarsTest [1 s]

All failures are the same:

Microsoft.Data.SqlClient.SqlException : A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 50 - Local Database Runtime error occurred. )

Conditions:

• Test Set 3
• .NET 8 and 9
• Windows
• Managed SNI
• Local SQL Server instance

Converting this back to a draft while I figure this out.

[mdaigle]

I wish azure pipelines would warn you about this stuff at compile time, it's so easy to make a mistake.