Azure Dev Summit Aspire Workshop

Azure Dev Summit Workshop

TL;DR: Summary

The last day of Azure Dev Summit was a workshop: Enhance your Application System with .NET Aspire.

Workshop Resources

The workshop provided several useful resources for learning and implementing .NET Aspire:

• Previous workshop recording on YouTube
• Workshop code and documentation on GitHub
• Aspire and Playwright integration example
• Official Aspire learning resources
• Complete Aspire integrations overview
• Aspire Discord community - where Aspire product managers and team members are active

Key Concepts and Setup

.NET 9 introduces automatic certificate rotation (renewal) in Kestrel, improving security management [citation needed].

It’s important to understand that Aspire itself isn’t deployed to production. Rather, it helps orchestrate the deployment process, but the Aspire framework remains a development and deployment tool.

Docker is required for local development when using Aspire.

Project Structure and Setup

Aspire projects can be created using Visual Studio, VS Code, or the CLI. The typical setup involves two key components:

1. ServiceDefaults Project: This is added as a project template to your solution. While not strictly necessary, adding a reference to this project and including a couple of lines to existing projects enables OpenTelemetry integration, significantly enhancing the dashboard experience.

2. AppHost Project: This contains references to all your projects and the integrations you want to use.

For projects in different repositories, you can add references by name and location, although solution references that link outside the repository work just as well.

Modular Usage

Aspire can be used in parts:

• ServiceDefaults only: Adds OpenTelemetry support and allows running a standalone dashboard
• AppHost only: Provides app visibility in the dashboard, but lacks OpenTelemetry integration

OpenTelemetry Integration

When you inject ILogger, it becomes an OpenTelemetry logger that integrates seamlessly with Application Insights and other monitoring tools. OpenTelemetry provides excellent features like tagging for better observability.

The OpenTelemetry data in the Aspire dashboard is stored in memory, as it’s designed as a development tool.

All ServiceDefaults functionality can be conditionally configured using IsDevelopment checks, though this still pulls in dependencies. We could potentially place the ServiceDefaults extension in our Application layer to avoid repetition, and it might be possible to convert it to .NET Standard for use in our interviewing system, as the OpenTelemetry packages appear to support .NET Standard.

Testing and Development

Since Aspire runs everything locally, it enables comprehensive integration testing. The framework provides discoverability features within tests through the Aspire.Hosting.Testing package. Tests can reference the AppHost project directly, and the entire system runs in memory for fast, reliable testing.

Deployment Strategy

The deployment functionality may not be directly relevant to our current infrastructure, as Aspire primarily targets Azure Container Apps. By default, services have internal endpoints unless explicitly configured with WithExternal methods.

Aspire distinguishes between native integrations and Azure-specific integrations (for example, Redis versus AzureRedis). Azure integrations use WithAzure methods, while local configuration typically uses RunAsContainer settings.

Azure Developer CLI Integration

The Azure Developer CLI (azd) provides several deployment commands:

• azd pipeline: Generates Bicep templates and YAML pipeline files
• azd up: Provisions infrastructure and deploys (avoid in production)
• azd deploy: Deploys to existing infrastructure

Configuration Management

Parameters can be added to the AppHost using AppParameter, which sources values from appsettings.json. These parameters appear as resources in the AppHost dashboard. Parameters can be marked as secrets, which automatically stores them in Azure Key Vault during deployment.

Development Experience

Visual Studio provides excellent tooling support for Aspire. You can add integrations by right-clicking on a project and selecting “Add > Aspire package,” which filters the NuGet package manager to show relevant Aspire packages.

The dashboard supports custom commands, which is a nice feature though probably not practical for most real-world scenarios. Health checks are implemented simply as URL endpoints.

It’s worth reiterating that the Aspire dashboard is designed for development, not production. Production environments should use dedicated observability dashboards that can properly display OpenTelemetry data.

Environment Variable Management

The .WithReference method automatically adds environment variables, while .AddEnvironment provides more control over variable naming. This flexibility is particularly useful for integrating with existing code that expects specific environment variable names.

For our specific use case, we likely shouldn’t seed Azure App Configuration (AAC) directly. Instead, we can create an AAC resource and reference it, without needing to populate it with endpoint variables since our application settings can override these values.

---

Note: The original rough notes for this post were converted into polished prose with assistance from GitHub Copilot. The original notes are preserved as HTML comments in the source file.