[POC — DO NOT MERGE] Managed Hosting SDK + sample extension (BlobPocExtension)

[gary-x-li]

Summary

This is a proof-of-concept, draft PR opened for discussion only — it is not intended to be merged. Nothing here is finalized; APIs, names, structure, and conventions are all up for debate. The goal is to make two things tangible:

1. A new opinionated hosting facade — Azure.Deployments.Extensibility.Hosting.Managed — that wraps the existing AspNetCore SDK with the platform-contract defaults a managed/platform-hosted extension needs (port binding, health endpoint, local-dev relaxations), so an extension author writes minimal boilerplate.
2. A realistic sample extension — BlobPocExtension — built on that facade, exercising real Azure Storage data-plane I/O to show the end-to-end authoring experience (typed handlers, cross-cutting behaviors, health checks, DI, error mapping).

What's in here

New SDK: Azure.Deployments.Extensibility.Hosting.Managed

• BicepExtension — a thin facade over ExtensionApplication exposing CreateBuilder, ConfigureServices, AddExtensionVersion, AddHealthCheck<T>, ConfigureApiExplorerExamples, and Run. Applies managed-hosting defaults: binds Kestrel to EXTENSION_PORT (default 8080), always maps GET /health, etc.
• DevelopmentHeaderBackfillStartupFilter — local-dev convenience that backfills platform-injected headers so the extension can be driven directly (Scalar UI / .http / curl) without the platform in front of it.

Sample: BlobPocExtension

• Scope intentionally minimal: a single Container resource type (Blob deferred), exact version 1.0.0, storage account assumed to pre-exist (control-plane out of scope).
• Typed handlers for preview / createOrUpdate / get / delete + a stub long-running-operation handler.
• Cross-cutting behaviors (mirroring the MagicEightBallExtension pattern) registered in the pipeline so handlers stay pure I/O:
  • AccountNameValidationBehavior — validates accountName (also an SSRF guard, ^[a-z0-9]{3,24}$)
  • ApiVersionValidationBehavior — rejects unsupported apiVersion
  • StorageExceptionHandlingBehavior — maps RequestFailedException → structured ErrorResponse (now surfacing storage error code + request id)
• Auth: DefaultAzureCredential only — az login locally, managed identity in cloud. No secrets/connection strings/Azurite.
• local-testing/ — a self-contained guide and tooling: README.md, requests.http, storage-account.bicep (account + Storage Blob Data Contributor role), acr.bicep (registry with anonymous pull disabled), and instructions to publish a self-contained linux-x64 single-file binary and push it as an OCI artifact via ORAS.

How to try it

See README.md: deploy storage-account.bicep, dotnet run, then drive the endpoints from requests.http (or the Scalar UI at /scalar/v2). The publishing section covers the self-contained binary + ORAS/ACR flow.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.18%. Comparing base (286d742) to head (7582fc5).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #376   +/-   ##
=======================================
  Coverage   52.18%   52.18%           
=======================================
  Files         108      108           
  Lines        2106     2106           
  Branches      235      235           
=======================================
  Hits         1099     1099           
  Misses        954      954           
  Partials       53       53           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.