Encryption Pipelines: Adds SDK-surface parity build to catch TypeLoad gaps by NaluTripician · Pull Request #5798 · Azure/azure-cosmos-dotnet-v3

NaluTripician · 2026-04-21T23:00:53Z

Problem

The Encryption and Encryption.Custom official release pipelines previously built each project only against the pinned Microsoft.Azure.Cosmos NuGet declared in the project file. That does not detect abstract members added to Container on master that lack an unconditional override in EncryptionContainer — the exact class of defect fixed by #5783 (SemanticRerankAsync TypeLoadException).

The customer-facing symptom from #5783:

System.TypeLoadException: Method SemanticRerankAsync in type Microsoft.Azure.Cosmos.Encryption.Custom.EncryptionContainer does not have an implementation.

Why a naive SDKREF build is not enough

The override was gated #if PREVIEW && SDKPROJECTREF. Any build that defines both symbols — which is what the existing PR-validation build (build-preview.yml) does, and what an obvious "build with SdkProjectRef=true" addition would also do — compiles the override back in and the missing-implementation condition never manifests:

Build mode	`PREVIEW`	`SDKPROJECTREF`	Override present?	Catches the bug?
Current default (NuGet ref, pinned `3.41.0-preview.0`)	❌	❌	— (no abstract either)	❌
`-p:IsPreview=true -p:SdkProjectRef=true`	✅	✅	✅	❌ (masks the defect)
New parity build (`DefineSdkProjectRefSymbol=false`)	✅	❌	❌	✅

The bug only manifests when PREVIEW is on and SDKPROJECTREF is off, linked against an SDK that contains the new abstract member. That is the exact surface of the shipped Encryption.Custom NuGet.

Change

Decouple the SDKPROJECTREF preprocessor define from the SdkProjectRef MSBuild property via a new DefineSdkProjectRefSymbol knob in both:
- Microsoft.Azure.Cosmos.Encryption.Custom/src/Microsoft.Azure.Cosmos.Encryption.Custom.csproj
- Microsoft.Azure.Cosmos.Encryption/src/Microsoft.Azure.Cosmos.Encryption.csproj
Default behaviour is unchanged: SdkProjectRef=true still sets SDKPROJECTREF. Pipelines can now opt out with -p:DefineSdkProjectRefSymbol=false.
Add two build steps to each encryption official release-gate template (templates/static-tools-encryption.yml, templates/static-tools-encryption-custom.yml):
- SDKREF build — -p:IsPreview=true -p:SdkProjectRef=true. Verifies the full project-reference path still compiles against master SDK source.
- NuGet-surface parity build — -p:IsPreview=true -p:SdkProjectRef=true -p:DefineSdkProjectRefSymbol=false. Links against master SDK source with the exact preprocessor surface of the shipped NuGet. Any newly-added abstract member on Container under #if PREVIEW without an unconditional override in EncryptionContainer now fails this step with CS0534.

Proof the pipeline catches #5783

I reverted #5783 in a worktree (virtual → abstract on Container.SemanticRerankAsync) and ran the new parity build for Encryption.Custom:

error CS0534: 'EncryptionContainer' does not implement inherited abstract
member 'Container.SemanticRerankAsync(string, IEnumerable<string>,
IDictionary<string, object>, CancellationToken)'
Build FAILED.

That is exactly the runtime TypeLoadException surface from the customer report, caught at compile time.

All six build permutations (default / SDKREF / parity × Encryption / Encryption.Custom) pass at the fixed state:

Project	Default (NuGet)	SDKREF	NuGet-surface parity
`Microsoft.Azure.Cosmos.Encryption`	✅	✅	✅
`Microsoft.Azure.Cosmos.Encryption.Custom`	✅	✅	✅

Type of change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update

Closing issues

Related to #5783.

azure-pipelines · 2026-04-21T23:01:09Z

Azure Pipelines: Successfully started running 1 pipeline(s).

… gaps The Encryption and Encryption.Custom official release pipelines previously built each project only against the pinned Microsoft.Azure.Cosmos NuGet. That does not detect abstract members added to Container on master that lack an unconditional override in EncryptionContainer - the exact class of defect fixed by PR #5783 (SemanticRerankAsync TypeLoadException). The override for the fixed method was gated '#if PREVIEW && SDKPROJECTREF', so a build that defines both symbols (the existing PR validation pattern) also masks the defect: the override is compiled back in and the missing- implementation condition never manifests. The bug only surfaces when the Encryption.Custom NuGet is built with PREVIEW on and SDKPROJECTREF off and is then loaded against an SDK that contains the new abstract member. This change: 1. Decouples the SDKPROJECTREF preprocessor define from the SdkProjectRef MSBuild property via a new DefineSdkProjectRefSymbol knob. Default behavior is unchanged: SdkProjectRef=true still sets SDKPROJECTREF. 2. Adds two build steps to each encryption official release-gate template: - SDKREF build: '-p:IsPreview=true -p:SdkProjectRef=true' - verifies the full project-reference path still compiles against master SDK source. - NuGet-surface parity build: '-p:IsPreview=true -p:SdkProjectRef=true -p:DefineSdkProjectRefSymbol=false' - links against master SDK source with the exact preprocessor surface of the shipped NuGet (PREVIEW on, SDKPROJECTREF off). Any newly-added abstract member on Container that lacks an unconditional override in EncryptionContainer now fails this step with CS0534. Verified locally by reverting PR #5783 in a worktree: the parity build for Encryption.Custom fails with CS0534 on SemanticRerankAsync, exactly catching the bug. All six build permutations (default + SDKREF + parity for both Encryption and Encryption.Custom) pass at the fixed state. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

azure-pipelines · 2026-04-21T23:11:19Z

Azure Pipelines: Successfully started running 1 pipeline(s).

kushagraThapar

Shall we add a new job that handles this for the CI pipeline for every PR? Otherwise, we will still miss this when developing, right?

NaluTripician · 2026-04-22T18:31:35Z

Shall we add a new job that handles this for the CI pipeline for every PR? Otherwise, we will still miss this when developing, right?

@kushagraThapar this should now trigger with every PR once merged

kushagraThapar

Shall we add a new job that handles this for the CI pipeline for every PR? Otherwise, we will still miss this when developing, right?

Adds the same NuGet-surface parity build (IsPreview=true, SdkProjectRef=true, DefineSdkProjectRefSymbol=false) to templates/build-preview.yml, which is invoked on every PR via azure-pipelines.yml. The existing release-gate copy in templates/static-tools-encryption{,-custom}.yml is kept as a belt-and-suspenders check, but only ran at release time because those templates are consumed exclusively by azure-pipelines-encryption-{custom-,}official.yml which use trigger: none / pr: none. This ensures new abstract members on Container under #if PREVIEW that lack an unconditional override in EncryptionContainer fail at PR-time with CS0534 instead of at customer runtime as TypeLoadException. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

azure-pipelines · 2026-04-22T22:31:54Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-04-23T17:43:26Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-04-23T20:44:57Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-04-23T21:32:40Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-04-23T22:12:34Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-04-24T20:55:51Z

Azure Pipelines: Successfully started running 1 pipeline(s).

kundadebdatta

LGTM.

NaluTripician requested review from FabianMeiswinkel, Pilchie, kirankumarkolli, kushagraThapar and sboshra as code owners April 21, 2026 23:00

NaluTripician force-pushed the users/ntripician/encryption-pipeline-sdkref branch from 5d167db to ed8ee9d Compare April 21, 2026 23:11

NaluTripician changed the title ~~Encryption Pipelines: Adds SDKREF build alongside default NuGet build~~ Encryption Pipelines: Adds SDK-surface parity build to catch TypeLoad gaps Apr 21, 2026

kushagraThapar reviewed Apr 22, 2026

View reviewed changes

Comment thread templates/static-tools-encryption.yml

Merge branch 'master' into users/ntripician/encryption-pipeline-sdkref

84832a5

NaluTripician requested a review from kirillg as a code owner April 23, 2026 20:44

NaluTripician force-pushed the users/ntripician/encryption-pipeline-sdkref branch from 09ea3e4 to 84832a5 Compare April 23, 2026 21:32

Merge branch 'master' into users/ntripician/encryption-pipeline-sdkref

15bc0bc

Merge branch 'master' into users/ntripician/encryption-pipeline-sdkref

639ffa7

kushagraThapar approved these changes Apr 24, 2026

View reviewed changes

kundadebdatta reviewed Apr 24, 2026

View reviewed changes

Comment thread Microsoft.Azure.Cosmos.Encryption/src/Microsoft.Azure.Cosmos.Encryption.csproj

kundadebdatta approved these changes Apr 24, 2026

View reviewed changes

ananth7592 approved these changes Apr 24, 2026

View reviewed changes

NaluTripician added the auto-merge Enables automation to merge PRs label Apr 24, 2026

microsoft-github-policy-service Bot enabled auto-merge (squash) April 24, 2026 21:48

microsoft-github-policy-service Bot merged commit ee8836e into master Apr 24, 2026
32 checks passed

microsoft-github-policy-service Bot deleted the users/ntripician/encryption-pipeline-sdkref branch April 24, 2026 22:14

Conversation

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

Uh oh!

Problem

Why a naive SDKREF build is not enough

Change

Proof the pipeline catches #5783

Type of change

Closing issues

Uh oh!

azure-pipelines Bot commented Apr 21, 2026

Uh oh!

azure-pipelines Bot commented Apr 21, 2026

Uh oh!

kushagraThapar left a comment

Choose a reason for hiding this comment

Uh oh!

NaluTripician commented Apr 22, 2026

Uh oh!

kushagraThapar left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

azure-pipelines Bot commented Apr 22, 2026

Uh oh!

azure-pipelines Bot commented Apr 23, 2026

Uh oh!

azure-pipelines Bot commented Apr 23, 2026

Uh oh!

azure-pipelines Bot commented Apr 23, 2026

Uh oh!

azure-pipelines Bot commented Apr 23, 2026

Uh oh!

azure-pipelines Bot commented Apr 24, 2026

Uh oh!

Uh oh!

kundadebdatta left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

NaluTripician commented Apr 21, 2026 •

edited

Loading