Governance Standards Application Dotnet - Azure/az-prototype GitHub Wiki

Dotnet

Standards for generated .NET/C# application code, including project structure, dependency management, Azure SDK patterns, and Azure Functions isolated worker model requirements.

Domain: application


Checks (5)

Check Description
STAN-CS-001 Use Azure SDK with DefaultAzureCredential: Always use DefaultAzureCredential from Azure.Identity for authenticating to Azure services. This works with managed identity in Azure and developer credentials locally.
STAN-CS-002 Complete Project Structure: Every generated .NET app must include a .csproj file with all NuGet PackageReferences, a Program.cs entry point, and all model/DTO classes referenced by services. No file may reference a type that is not defined in the generated output.
STAN-CS-003 Azure Functions Isolated Worker Model: All C# Azure Functions must target the .NET isolated worker model using Microsoft.Azure.Functions.Worker (not the in-process model). Must include host.json (version 2.0) and local.settings.json with all required app settings.
STAN-CS-004 Configuration via appsettings.json: Use IConfiguration with appsettings.json for all configuration. Never hardcode endpoints, connection strings, or secrets. Use the Options pattern for strongly-typed settings.
STAN-CS-005 Dependency Injection: Use IServiceCollection for DI registration. All services, repositories, and Azure SDK clients must be registered in Program.cs. Use interface-based abstractions for testability.

STAN-CS-001

Use Azure SDK with DefaultAzureCredential: Always use DefaultAzureCredential from Azure.Identity for authenticating to Azure services. This works with managed identity in Azure and developer credentials locally.

Rationale: DefaultAzureCredential provides seamless authentication across local dev and managed identity in production.
Agents: csharp-developer

Examples

  • using Azure.Identity;
  • var credential = new DefaultAzureCredential();
  • Never pass connection strings when managed identity is available

STAN-CS-002

Complete Project Structure: Every generated .NET app must include a .csproj file with all NuGet PackageReferences, a Program.cs entry point, and all model/DTO classes referenced by services. No file may reference a type that is not defined in the generated output.

Rationale: Complete outputs enable downstream stages to reference resources without hardcoding.
Agents: csharp-developer

Examples

  • MyApp.csproj — project file with all PackageReferences
  • Program.cs — entry point with DI registration
  • Models/Project.cs — every referenced model class must exist
  • If a service references 'ProjectDto', that class must be generated

STAN-CS-003

Azure Functions Isolated Worker Model: All C# Azure Functions must target the .NET isolated worker model using Microsoft.Azure.Functions.Worker (not the in-process model). Must include host.json (version 2.0) and local.settings.json with all required app settings.

Rationale: The isolated worker model provides better dependency isolation and .NET version flexibility.
Agents: csharp-developer

Examples

  • Target net8.0 with Microsoft.Azure.Functions.Worker packages
  • host.json with version 2.0 extensionBundle
  • local.settings.json with FUNCTIONS_WORKER_RUNTIME = dotnet-isolated
  • Program.cs with HostBuilder configuration

STAN-CS-004

Configuration via appsettings.json: Use IConfiguration with appsettings.json for all configuration. Never hardcode endpoints, connection strings, or secrets. Use the Options pattern for strongly-typed settings.

Rationale: Externalized configuration supports environment-specific settings without code changes.
Agents: csharp-developer

Examples

  • builder.Configuration.AddJsonFile("appsettings.json")
  • services.Configure(config.GetSection("MyOptions"))
  • Never hardcode URLs, ports, or service endpoints

STAN-CS-005

Dependency Injection: Use IServiceCollection for DI registration. All services, repositories, and Azure SDK clients must be registered in Program.cs. Use interface-based abstractions for testability.

Rationale: Pinned dependencies ensure reproducible builds and prevent unexpected breaking changes.
Agents: csharp-developer

Examples

  • builder.Services.AddSingleton<IMyService, MyService>();
  • builder.Services.AddAzureClients(b => b.AddBlobServiceClient(...));
  • Register all services used by controllers/functions in Program.cs

⚠️ **GitHub.com Fallback** ⚠️