Add cleanroom SDK CLI samples and SDK walkthrough doc

[Shreya (ShreyaSangwa)]

Purpose

Adds SDK-based command-line samples for both management plane and frontend dataplane flows, and introduces a full SDK walkthrough document that replaces the managedcleanroom CLI dependency for this path.

Does this introduce a breaking change?

• Yes
• No

Pull Request Type

What kind of change does this Pull Request introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Documentation content changes
• Other... Please describe:

Summary of All Changes

• Added a new end-to-end SDK guide in README-SDK.md covering setup, auth modes, workflow steps, and troubleshooting for cleanroom-mgmt + afe commands.
• Added a management-plane CLI sample project in packages\mgmt-sample\CleanRoomMgmtSample.csproj and packages\mgmt-sample\Program.cs.
• Management CLI implements collaboration operations: create, get, list, delete, enable-workload, add-collaborator, recover, pause, resume, get-readonly-kubeconfig.
• Management CLI also adds consortia operations: create, get, list, delete.
• Added a frontend dataplane CLI sample project in packages\sample\AnalyticsFrontendSample.csproj and packages\sample\Program.cs.
• Frontend CLI supports endpoint-based operations for collaborations, analytics, OIDC, invitations, datasets, consent, queries, runs, secrets, and audit events.
• Frontend CLI includes both auth paths: DefaultAzureCredential and MSAL device-code, plus optional insecure TLS mode for dev/test.
• Added repository-level NuGet source config in NuGet.Config, and per-project NuGet configs inpackages\mgmt-sample\NuGet.config and packages\sample\NuGet.config, to resolve local package artifacts.
• Updated ignore behavior in .gitignore to preserve sample sources under packages/sample while still ignoring generic package/build outputs.
• Added local package artifacts required by the sample projects: packages\Azure.ResourceManager.CleanRoom.1.0.0-alpha.20260603.1.nupkg and packages\Azure.Cleanroom.Analytics.Frontend.Client.1.0.0-beta.1.nupkg.

How to Test

• Get the code

git clone https://github.com/ShreyaSangwa/azure-cleanroom-samples.git
cd azure-cleanroom-samples
git checkout sdk_update

• Build and validate frontend sample:

dotnet restorepackages\sample\AnalyticsFrontendSample.csproj
dotnet build packages\sample\AnalyticsFrontendSample.csproj -nologo
dotnet run --project packages\sample\AnalyticsFrontendSample.csproj -- --help

• Build and validate management sample:

dotnet restore packages\mgmt-sample\CleanRoomMgmtSample.csproj
dotnet build packages\mgmt-sample\CleanRoomMgmtSample.csproj -nologo
dotnet run --project packages\mgmt-sample\CleanRoomMgmtSample.csproj -- --help

Expected Result

Verify that the following are valid

• Both projects restore and build successfully.
• Help output is displayed for both CLIs.
• No unintended generated runtime artifacts are included in the PR.

[yrcvohra]

Can we create a new csproject for samples, and use the sdk generated from above inside the .cs file for testing?

[yrcvohra]

What needs to be added if the goal is “create packages for two folders”
If by “create packages” you mean the repo should generate those .nupkg files instead of checking them in manually, then you need a packaging step for each SDK source project.

1. Add packable SDK project(s)
   You need the actual SDK source projects somewhere, for example:

sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj
sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj
Those projects must include package metadata and be packable, e.g.:

sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj


net8.0
false
true
Azure.ResourceManager.CleanRoom
and similarly for frontend:

sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj


net8.0
true
Azure.Cleanroom.Analytics.Frontend.Client
1.0.0-beta.1
2. Add a pack command for both projects
You need a build script or workflow that runs something like:

pack-sdks.sh
dotnet pack sdk/management/Azure.ResourceManager.CleanRoom/Azure.ResourceManager.CleanRoom.csproj -c Release -o ./packages
dotnet pack sdk/frontend/Azure.Cleanroom.Analytics.Frontend.Client/Azure.Cleanroom.Analytics.Frontend.Client.csproj -c Release -o ./packages

That is the missing “create packages for two folders” step.

3. Ensure sample projects restore from that output folder
   This part is already mostly done.

Repo root NuGet.Config points to:

NuGet.Config

Per-sample NuGet.config points to:

packages/mgmt-sample/NuGet.config
v2

and same for packages/sample/NuGet.config.

That means each sample looks one directory up, i.e. packages/, where the .nupkg files live.

[yrcvohra]

This looks directionally right for consuming local SDK packages, but I think we’re still missing the package-production side of the flow.

The expectation for this change was to support two separately generated NuGet packages — one for the management SDK and one for the frontend SDK — and then use those packages from the sample Program.cs apps. Right now the PR adds the sample consumers and local NuGet.config files, but it appears to rely on checked-in .nupkg artifacts rather than defining how those packages are actually produced.

A few things I think we should add/clarify:

Source-of-truth for package generation

Where are the SDK source projects that produce:
Azure.ResourceManager.CleanRoom
Azure.Cleanroom.Analytics.Frontend.Client
We should have a documented or scripted dotnet pack flow for both.
Package output location

The two sample projects should remain normal PackageReference consumers of those package IDs/versions.
NuGet.config should point to the generated package feed location.
Docs/build instructions

We should document the expected sequence explicitly:
build/pack management SDK
build/pack frontend SDK
restore/build mgmt-sample
restore/build sample
Ignore rules

Suggested direction:

add a script/workflow that runs dotnet pack for both SDK projects
output packages to a dedicated local feed folder
update NuGet.config to consume from that folder
avoid relying on committed .nupkg binaries as the long-term model
If you want, I can also rewrite this into a shorter, more direct review comment for inline PR use