feat: add azure.provisioning extension (C# CDK importer)

[m-nash]

Summary

Adds an azd extension (azure.provisioning) that enables defining Azure infrastructure in C# using Azure.Provisioning instead of Bicep. Built on the new importer-provider capability from #7452.

The extension compiles C# to Bicep as an intermediate step — azd's built-in Bicep provider handles deployment, preview, state tracking, and destroy. Zero changes to azd core.

How it works

# azure.yaml
infra:
  importer:
    name: csharp
    options:
      path: infra

The user writes infra/infra.cs (or a .csproj project) using Azure.Provisioning, then runs azd up as normal. The extension:

1. Detects the C# entry point (single .cs file or .csproj project)
2. Runs dotnet run to compile C# to Bicep
3. Returns the generated Bicep files to azd via the importer interface
4. azd's Bicep provider deploys, previews, or destroys as usual

Testing

All scenarios verified E2E against live Azure:

Scenario	Result
Single .cs file provision	Pass
.csproj project provision	Pass
azd provision --preview	Pass
azd down	Pass
azd init --template	Pass
Options forwarding from azure.yaml	Pass
Full todo app (7 resources + Playwright test)	Pass

Sample repo: m-nash/todo-csharp-cosmos-sql-dotnet — full todo app with Cosmos DB, App Service, Key Vault, App Insights, all defined in a single infra.cs file.

Gaps to consider

1. Auto-detection — infra.importer config is required

Today, azd auto-detects .bicep → Bicep and .tf → Terraform without any infra: config in azure.yaml. The same should work for C# — a user should be able to drop an infra.cs into the infra/ folder and run azd up without any yaml changes.

Currently this requires the explicit infra.importer block because the auto-detection path does not consult extension importers. Ideally, when no provider is detected from built-in file checks, azd would ask each installed extension importer if it can handle the current infra directory, and let the extension decide based on whatever criteria makes sense (file types, markers, etc.). This keeps azd core language-agnostic while letting extensions opt in to auto-detection.

2. CLI argument passthrough

The extension forwards infra.importer.options from azure.yaml as --key value args to the C# program. This works for static configuration but there is no way to pass runtime arguments from the CLI (e.g. azd provision -- --region westus3).

We would strongly encourage azd to support CLI arg passthrough to importer extensions. Code-based CDK programs are written in full programming languages — C#, TypeScript, Java, Python — and developers will naturally use command-line arguments to parameterize their infrastructure. If a standalone dotnet run infra.cs -- --region westus3 (or npx ts-node infra.ts -- --region westus3) works but the same program requires manual wiring through azure.yaml options when run via azd, that friction becomes a real adoption blocker. Users should not have to restructure their code to work with azd.