`build2.proj` All the Things by benrr101 · Pull Request #4204 · dotnet/SqlClient

benrr101 · 2026-04-17T20:54:22Z

Description

This PR moves all projects in the repository to be built, tested, and packed with build2.proj. This style was pioneered with the merge project and this PR migrates all the other projects to this format. Versioning has been updated for each package as well, and explained thoroughly in BUILDGUIDE.md. A new TESTGUIDE.md has been added as well.

🤖

Applied changes to CI/PR pipelines after build2.proj changes went into effect. In most cases, there were no changes necessary since CI/PR pipelines currently directly build the projects via a dotnet.
Helped with debugging various official/non-official pipeline failures
Wrote TESTGUIDE.md
Updated instructions for agents

Testing

Local tests of build2.proj is working as intended
Non-official build pipeline is passing:
~~https://sqlclientdrivers.visualstudio.com/ADO.Net/_build/results?buildId=148136&view=results~~
https://sqlclientdrivers.visualstudio.com/ADO.Net/_build/results?buildId=148854&view=results
CI/PR pipeline validation is forthcoming.

Work to do before completing PR

[ ] Validate PR/CI pipeline
[ ] Validate Non-official pipeline
[ ] Update agent instructions
[x] Rename build2.proj to build.proj?

cheenamalhotra · 2026-04-17T22:01:41Z

A Big YES to the last item in your checklist 🎉

paulmedynski

Loving the improvements and consolidation here - looking forward to porting this back to the release branches for a consistent experience.

A few questions and some comment typos to fix.

paulmedynski · 2026-04-20T15:18:48Z

-        -p:MdsPackageVersion=${{ parameters.mdsPackageVersion }}
-        -p:AkvPackageVersion=${{ parameters.akvPackageVersion }}
-        -p:PackageOutputPath=$(packagePath)
+      command: pack


I thought build2.proj had Pack targets...

It does, but the pattern for the CI/PR pipelines seems to overwhelmingly be to directly build the csproj files. So rather than change the outlier (AKV Provider using build.proj) to a different outlier (AKV Provider using build2.proj), I changed it to follow the pattern for the other CI/PR pack tasks.

Please note that all of this will be obliterated as part of this semester's pipeline work :)

paulmedynski · 2026-04-20T15:19:18Z

-        configuration: '${{ parameters.buildConfiguration }}'
-        msbuildArguments: >-
-          -t:BuildAkvProvider
+        command: build


No Build target for AKV?

Same comment as pack comment applies. Rather than move it from build.proj to build2.proj, I updated it to use the csproj directly like all the other projects in the CI/PR pipelines.

paulmedynski · 2026-04-20T15:21:32Z

+
+    pool:
+      name: Azure Pipelines
+      vmImage: ubuntu-latest


I believe we're supposed to use only our 1ES images. The other extensions packages are doing this wrong as well. Just FYI - we will fix this in a future PR once we have appropriate 1ES images setup.

Well ... it's been like that since at least 2/24/26. 🤷‍♂️
Not sure why the entire file looks new - this was one of the commits I let the 🤖 handle.

paulmedynski · 2026-04-20T15:24:43Z

-  - name: packageName
+  # List of packages that the package being built with this job depends on. Each entry in the
+  # object should have the fields:
+  # * artifactName - Name of the artifact to published in a previous job that contains the desired


Name of the artifact pubished in a previous ...

paulmedynski · 2026-04-20T15:25:42Z

-      # Inform OneBranch that files put in this directory should be uploaded as artifacts.
-      ob_outputDirectory: $(PACK_OUTPUT)
+      # Placeholder for dependency package arguments. This will be constructed later as it depends
+      # on scripting to decompose parameters.dependencies.


parameters.dependencies.

🤔 Isn't that what I have?

paulmedynski · 2026-04-20T15:29:36Z

-              publishSymbols: ${{ parameters.publishSymbols }}
-              downloadArtifacts:
+              dependencies:
                - artifactName: '${{ parameters.loggingArtifactsName }}'


I like this approach - obvious and readable.

paulmedynski · 2026-04-20T15:48:48Z

+## Versioning
+
+Versioning can be accomplished by using a mix of different parameters to the `build2.proj` targets:
+`PackageVersion<TargetProject>`, `BuildNumber`, `and `BuildSuffix`. Using these in different combinations, can generate


paulmedynski · 2026-04-20T15:49:53Z

-### Running Tests with Reference Type
+The above documentation is the default mode of operation, and is the recommended mode for most developers. However,
+`build2.proj` supports "package mode" builds. In this mode, instead of projects depending on other projects, they
+depend on NuGet packages. This mode is useful for verifying that packages work witheach other, especially in automated


paulmedynski · 2026-04-20T15:51:30Z

      <Link>xunit.runner.json</Link>
    </None>
-
-    <None Include="$(RepoRoot)src/Microsoft.Data.SqlClient/tests/tools/Microsoft.Data.SqlClient.TestUtilities/CodeCoverage.runsettings">


Where did these copy commands go?

Not necessary anymore, right? They got put into the build2.proj as what gets included if code coverage is turned on?

<TestCodeCoverage Condition="'$(TestCodeCoverage)' == ''">true</TestCodeCoverage> <TestCodeCoverageArgument Condition="'$(TestCodeCoverage.ToLower())' == 'true'"> --collect "Code coverage" --settings "$(RepoRoot)src/Microsoft.Data.SqlClient/tests/tools/Microsoft.Data.SqlClient.TestUtilities/CodeCoverage.runsettings" </TestCodeCoverageArgument>

mdaigle

All the changes make sense to me. Look forward to seeing some pipeline runs.

mdaigle · 2026-04-20T20:52:22Z

+The above documentation is the default mode of operation, and is the recommended mode for most developers. However,
+`build2.proj` supports "package mode" builds. In this mode, instead of projects depending on other projects, they
+depend on NuGet packages. This mode is useful for verifying that packages work witheach other, especially in automated
+build scenarios. For completeness, and debugging of autoamted builds, this section documents behavior of "package mode".


✏️ automated

mdaigle · 2026-04-20T20:54:15Z

@@ -0,0 +1,311 @@
+# Test Guide for Microsoft.Data.SqlClient


Can we link to this from BUILDGUIDE rather than duplicating the content?

For the sections I rewrote, yes, we have links to the TESTGUIDE.

For more
information about test procedures, including config file setup, see TESTGUIDE.md.

Manual test prerequisites and configuration are covered in TESTGUIDE.md.

For the stuff after the sections I rewrote ... well no, I didn't because I guess I figured everything after the sections I rewrote were just about managing runtime switches (which imo, doesn't seem like a great place to put them, but whatever - it's outside the scope of this PR). Since I had the 🤖 write the TESTGUIDE, I'll just tell it to include the stuff about perf testing and databases and whatever.

cheenamalhotra · 2026-04-21T19:11:33Z

+
+| `<build_target>`            | Description                                                                     |
+|:----------------------------|:--------------------------------------------------------------------------------|
+| `Build`                     | Builds all projects for all platforms                                           |


Is this also the default target?

We should support "msbuild" on the repository (as we've had before) that would build all projects and create NuGet packages for validation with default configuration setup.

cheenamalhotra · 2026-04-21T19:12:22Z

-dotnet test "src/Microsoft.Data.SqlClient/tests/FunctionalTests/Microsoft.Data.SqlClient.FunctionalTests.csproj" \
-  -p:Configuration=Release \
-  --filter "category!=failing&category!=flaky&category!=interactive"
+msbuild build2.proj -t:TestSqlClientUnit


There shouldn't be a need to specify name of proj file, if this is the only project file on root folder.

cheenamalhotra · 2026-04-21T19:12:45Z

Rename this to build.proj?

Copilot

Pull request overview

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

Comments suppressed due to low confidence (1)

.github/prompts/release-notes.prompt.md:35

The Version Source table still points at files that were removed/renamed in this PR (tools/props/Versions.props, *Versions.props files). This will cause the release-notes prompt to guide agents to non-existent paths and incorrect version properties. Update the table to reference the new per-package Versions.props files (e.g., src/Microsoft.Data.SqlClient/Versions.props, src/Microsoft.Data.SqlClient.Extensions/.../Versions.props, etc.) and the correct property names.

| Package | Version Source | Dependency Source |
|---------|---------------|-------------------|
| `Microsoft.Data.SqlClient` | [tools/props/Versions.props](tools/props/Versions.props) (`MdsVersionDefault`) | [Directory.Packages.props](Directory.Packages.props) and the [project file](src/Microsoft.Data.SqlClient/src/Microsoft.Data.SqlClient.csproj) |
| `AzureKeyVaultProvider` | [tools/props/Versions.props](tools/props/Versions.props) (`AkvVersionDefault`) | [AKV project file](src/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider/src/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider.csproj) and [Directory.Packages.props](Directory.Packages.props) |
| `Microsoft.SqlServer.Server` | [tools/props/Versions.props](tools/props/Versions.props) (`SqlServerPackageVersion`) | [SqlServer project file](src/Microsoft.SqlServer.Server/Microsoft.SqlServer.Server.csproj) |
| `Extensions.Abstractions` | [AbstractionsVersions.props](src/Microsoft.Data.SqlClient.Extensions/Abstractions/src/AbstractionsVersions.props) | [Abstractions.csproj](src/Microsoft.Data.SqlClient.Extensions/Abstractions/src/Abstractions.csproj) |
| `Extensions.Azure` | [AzureVersions.props](src/Microsoft.Data.SqlClient.Extensions/Azure/src/AzureVersions.props) | [Azure.csproj](src/Microsoft.Data.SqlClient.Extensions/Azure/src/Azure.csproj) |
| `Internal.Logging` | [LoggingVersions.props](src/Microsoft.Data.SqlClient.Internal/Logging/src/LoggingVersions.props) | [Logging.csproj](src/Microsoft.Data.SqlClient.Internal/Logging/src/Logging.csproj) |

Copilot · 2026-04-22T00:31:53Z

+
+    pool:
+      name: Azure Pipelines
+      vmImage: ubuntu-latest


This job runs dotnet pack for Microsoft.SqlServer.Server (targets net46;netstandard2.0) on ubuntu-latest. Building net46 TFMs on Linux typically fails without additional reference-assembly packages/config, so this is very likely to break CI. Consider moving this job to a Windows pool (e.g., windows-latest) or adjusting the project/pack step to avoid net46 on non-Windows agents.

Suggested change

vmImage: ubuntu-latest

vmImage: windows-latest

Copilot · 2026-04-22T00:31:53Z

  # MDS library NuGet package version
  # NOTE: This differs from the other structures! MdsVersions.props will deconstruct a provided
  #    package version and build an assembly version from it. If the build number is included
  #    before the "-" the build number will be appended again, generating an invalid file version.
-  # @TODO: This is a band-aid to ensure that CI builds until we can centralize versioning.
  - name: mdsPackageVersion
    value: 7.0.0-ci$(AssemblyBuildNumber)

+  # SqlServer library NuGet package version
+  # NOTE: SqlServer's version props derive file version from the package version by appending the
+  #    assembly build number, so this must remain a three-part SemVer base with a prerelease
+  #    suffix, not a four-part numeric version.
+  - name: sqlServerPackageVersion
+    value: 1.0.0-ci$(AssemblyBuildNumber)


mdsPackageVersion/sqlServerPackageVersion are using $(AssemblyBuildNumber), but this file defines the build-number variable as assemblyBuildNumber (lowercase). Even if ADO macro expansion treats names case-insensitively, this is inconsistent with the rest of the file and easy to misread. Also, the comment above mdsPackageVersion still references MdsVersions.props, but the repo now uses Versions.props/SqlClientPackageVersion. Please align the variable name usage and update the comment to match the current versioning files/properties.

Copilot · 2026-04-22T00:31:53Z

+      <!-- Put the ThisAssembly class in the assembly's name namespace by default. -->
+      <ThisAssemblyNamespace Condition="'$(ThisAssemblyNamespace)' == ''">$(AssemblyName)</ThisAssemblyNamespace>


Changing the default ThisAssembly namespace from System to $(AssemblyName) is a breaking behavior change for any code that reflects or references System.ThisAssembly (e.g., the stress runner currently looks up assembly.GetType("System.ThisAssembly") and will now return null). Either keep System as the default for backward-compat (and explicitly override ThisAssemblyNamespace in the projects that need uniqueness) or update all downstream consumers that assume System.ThisAssembly.

Copilot

Pull request overview

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

Copilot · 2026-04-22T18:52:54Z

+          configurationToPack: ${{ parameters.buildConfiguration }}
+          packDirectory: $(dotnetPackagesDir)
+          verbosityToPack: ${{ parameters.dotnetVerbosity }}
+          buildProperties: SqlServerPackageVersion=${{ parameters.sqlServerPackageVersion }}


dotnet pack only passes SqlServerPackageVersion, but src/Microsoft.SqlServer.Server/Versions.props computes SqlServerFileVersion by appending $(FileVersionBuildNumber) (derived from $(BuildNumber)). Since BuildNumber isn't provided here, FileVersionBuildNumber falls back to 0 and file versions will come out as x.y.z.0. Pass BuildNumber=$(Build.BuildNumber) (and any other required version props) via buildProperties so file versions reflect the build.

Suggested change

buildProperties: SqlServerPackageVersion=${{ parameters.sqlServerPackageVersion }}

buildProperties: SqlServerPackageVersion=${{ parameters.sqlServerPackageVersion }};BuildNumber=$(Build.BuildNumber)

Copilot · 2026-04-22T18:52:55Z

 | Package | Version Source | Dependency Source |
 |---------|---------------|-------------------|
 | `Microsoft.Data.SqlClient` | [tools/props/Versions.props](tools/props/Versions.props) (`MdsVersionDefault`) | [Directory.Packages.props](Directory.Packages.props) and the [project file](src/Microsoft.Data.SqlClient/src/Microsoft.Data.SqlClient.csproj) |
-| `AzureKeyVaultProvider` | [tools/props/Versions.props](tools/props/Versions.props) (`AkvVersionDefault`) | [AKV project file](src/Microsoft.Data.SqlClient/add-ons/AzureKeyVaultProvider/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider.csproj) and [Directory.Packages.props](Directory.Packages.props) |
+| `AzureKeyVaultProvider` | [tools/props/Versions.props](tools/props/Versions.props) (`AkvVersionDefault`) | [AKV project file](src/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider/src/Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider.csproj) and [Directory.Packages.props](Directory.Packages.props) |
 | `Microsoft.SqlServer.Server` | [tools/props/Versions.props](tools/props/Versions.props) (`SqlServerPackageVersion`) | [SqlServer project file](src/Microsoft.SqlServer.Server/Microsoft.SqlServer.Server.csproj) |
 | `Extensions.Abstractions` | [AbstractionsVersions.props](src/Microsoft.Data.SqlClient.Extensions/Abstractions/src/AbstractionsVersions.props) | [Abstractions.csproj](src/Microsoft.Data.SqlClient.Extensions/Abstractions/src/Abstractions.csproj) |
 | `Extensions.Azure` | [AzureVersions.props](src/Microsoft.Data.SqlClient.Extensions/Azure/src/AzureVersions.props) | [Azure.csproj](src/Microsoft.Data.SqlClient.Extensions/Azure/src/Azure.csproj) |


The versioning/dependency source table is now stale: it still points at tools/props/Versions.props and *Versions.props files that were removed/renamed in this PR (e.g., SqlClient now uses src/Microsoft.Data.SqlClient/Versions.props, and Abstractions/Azure version files are now src/.../Versions.props). Update the table to reference the current versioning sources so the prompt doesn’t direct agents to non-existent files.

Copilot · 2026-04-22T18:52:55Z

    <PackageVersion
      Include="Microsoft.Data.SqlClient"
-      Version="$(MdsPackageVersion)" />
+      Version="$(SqlClientPackageVersion)" />
    <PackageVersion
      Include="Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider"
-      Version="$(AkvPackageVersion)" />
+      Version="$(AkvProviderPackageVersion)" />


In Package reference builds, Microsoft.Data.SqlClient now takes a package reference on Microsoft.SqlServer.Server (see src/Microsoft.Data.SqlClient/src/Microsoft.Data.SqlClient.csproj), and CI now builds/publishes a SqlServer artifact with version $(sqlServerPackageVersion) (e.g., 1.0.0-ci...). However, Directory.Packages.props hardcodes Microsoft.SqlServer.Server to 1.0.0, which will cause restore to look for the wrong version when consuming the locally-built artifact. Consider versioning Microsoft.SqlServer.Server here via a $(SqlServerPackageVersion) property (and passing it in CI) for consistency with the other in-repo packages.

…oj norms

…r to build2.proj norms

…csproj, just like all the other projects.

Migrate the SqlClient csproj files to the same pattern as the other projects.

…ctory.Build.props

…aring too.

benrr101 added this to the 7.1.0-preview1 milestone Apr 17, 2026

Copilot AI review requested due to automatic review settings April 17, 2026 20:54

benrr101 added Area\Documentation Use this for issues that requires changes in public documentations/samples. Area\Engineering Use this for issues that are targeted for changes in the 'eng' folder or build systems. labels Apr 17, 2026

github-project-automation Bot added this to SqlClient Board Apr 17, 2026

github-project-automation Bot moved this to To triage in SqlClient Board Apr 17, 2026

Copilot started reviewing on behalf of benrr101 April 17, 2026 20:54 View session

This comment was marked as outdated.

Sign in to view

paulmedynski moved this from To triage to In review in SqlClient Board Apr 20, 2026

paulmedynski self-assigned this Apr 20, 2026

paulmedynski requested changes Apr 20, 2026

View reviewed changes

github-project-automation Bot moved this from In review to In progress in SqlClient Board Apr 20, 2026

mdaigle reviewed Apr 20, 2026

View reviewed changes

benrr101 force-pushed the dev/russellben/build2 branch from 9c8cd1c to 6be4e7a Compare April 20, 2026 23:07

paulmedynski added the Hotfix Candidate 🚑 Issues/PRs that are candidate for backporting to earlier supported versions. label Apr 21, 2026

cheenamalhotra reviewed Apr 21, 2026

View reviewed changes

Comment thread build.proj

Copy link
Copy Markdown

Member

cheenamalhotra Apr 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rename this to build.proj?

Copilot AI review requested due to automatic review settings April 22, 2026 00:26

benrr101 force-pushed the dev/russellben/build2 branch from 6be4e7a to 2112bb8 Compare April 22, 2026 00:26

Copilot started reviewing on behalf of benrr101 April 22, 2026 00:27 View session

Copilot AI reviewed Apr 22, 2026

View reviewed changes

benrr101 force-pushed the dev/russellben/build2 branch from 2112bb8 to 3976008 Compare April 22, 2026 17:20

Copilot AI review requested due to automatic review settings April 22, 2026 18:46

Copilot started reviewing on behalf of benrr101 April 22, 2026 18:47 View session

Copilot AI reviewed Apr 22, 2026

View reviewed changes

benrr101 added 3 commits April 22, 2026 13:56

Adding steps/job for OneBranch pipeline builds to utilize build2.proj.

8a60f20

Default ThisAssembly namespace to $$AssemblyName$

0814c1d

Migrate Microsoft.SqlServer.Server to build2.proj norms

f67edb4

benrr101 added 23 commits April 22, 2026 13:56

Wire official pipeline to use build2.proj for SqlSever

076947c

🤖 Wire SqlServer to CI/PR pipeline.

7480710

Migrate Microsoft.Data.SqlClient.Logging to build2.proj norms

60f8426

Wire official pipeline to use build2.proj for Logging

d1a8dd5

Migrate Microsoft.Data.SqlClient.Extensions.Abstractions to build2.pr…

3b5669e

…oj norms

Wire official pipeline to use build2.proj for Abstractions

9ccac48

Migrate Microsoft.Data.SqlClient.Extensions.Azure to build2.proj norms

88a200b

Wire official pipeline to use build2.proj for Azure

14ebf6a

Move AKV Provider to root folder (since it is a package we release)

4f7b6e7

Migrate Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvide…

67a928d

…r to build2.proj norms

Wire official pipeline to use build2.proj for AkvProvider

55f500a

Migrate CI/PR pipeline AKV Provider build steps to directly call the …

5091c8c

…csproj, just like all the other projects.

Mds => SqlClient

f886fd1

Migrate the SqlClient csproj files to the same pattern as the other projects.

Wire official pipeline to use build2.proj for SqlClient

7c0d5fa

Wire CI/PR pipelines to use build2.proj for SqlClient

0a197d0

Delete obsolete pipeline files and build.proj

82b9451

Update documentation in build2.proj

776e279

Remove global versions.props and move build number coalescing to Dire…

5966248

…ctory.Build.props

Remove tool restore from ref project

fd63230

Add utility targets

293a6f6

BUILDGUIDE update and new TESTGUIDE

cda1a15

Round one of code review changes

d417a54

build2.proj => build.proj

1f5e944

benrr101 force-pushed the dev/russellben/build2 branch from dea9239 to 1f5e944 Compare April 22, 2026 19:01

Nobody cares how pretty I make the commits, so I might as well stop c…

bb5101f

…aring too.

Copilot AI review requested due to automatic review settings April 22, 2026 19:55

Copilot started reviewing on behalf of benrr101 April 22, 2026 19:55 View session

This comment was marked as outdated.

Sign in to view

Oh look something else is broken

27ebe64

		<!-- Put the ThisAssembly class in the assembly's name namespace by default. -->
		<ThisAssemblyNamespace Condition="'$(ThisAssemblyNamespace)' == ''">$(AssemblyName)</ThisAssemblyNamespace>

	buildProperties: SqlServerPackageVersion=${{ parameters.sqlServerPackageVersion }}
	buildProperties: SqlServerPackageVersion=${{ parameters.sqlServerPackageVersion }};BuildNumber=$(Build.BuildNumber)

Conversation

benrr101 commented Apr 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

🤖

Testing

Work to do before completing PR

Uh oh!

This comment was marked as outdated.

Uh oh!

cheenamalhotra commented Apr 17, 2026

Uh oh!

paulmedynski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdaigle left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mdaigle Apr 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

benrr101 commented Apr 17, 2026 •

edited

Loading

mdaigle Apr 20, 2026 •

edited

Loading