Setting Up .NET Aspire on Linux

Installing the Aspire CLI

[0:48 - 2:20] Tim begins at aspire.dev, noting that the project recently rebranded from "Aspire.NET" to just "Aspire." The rename reflects the tool's expanding scope: while Aspire is still built on .NET and primarily serves .NET developers, it now supports TypeScript app hosts as well, and more language integrations are on the roadmap.

The installation itself is a single bash command copied from the Aspire documentation for version 9.2:

dotnet tool install -g aspirate

dotnet tool install -g aspirate

After running the installer, restart your terminal session so the tool registers on your PATH. Without the restart, your shell will not recognize the new command.

Then confirm the installation completed correctly:

aspire --version

aspire --version

If the version number prints, the CLI is ready. That two-step process (install, verify) is the entire setup on the terminal side.

Configuring the VS Code Extension

[2:23 - 3:30] With the CLI installed, the next step is the VS Code extension. Open the Extensions panel, search for "Aspire," and install the official extension published by Microsoft. The extension adds project scaffolding, launch configuration support, and integration with the Aspire dashboard.

After installing, VS Code runs a verification step to confirm that the CLI and extension are aligned. Tim notes that the extension can also scaffold a new project directly through the command palette, though he opts for the CLI approach instead. That choice is deliberate: knowing the CLI means you are never stuck when a GUI tool misbehaves. When the VS Code template picker failed to surface Aspire templates after installation, the CLI provided an immediate fallback.

Scaffolding the Starter Project

[3:30 - 6:42] Rather than using the VS Code "Create New .NET Project" command (which intermittently failed to discover the Aspire templates), Tim drops into the terminal and runs:

aspire new

aspire new

Several template choices appear in the interactive prompt. For a production application, you would typically select the empty C# app host and build from there. For learning purposes, Tim selects the Starter App, which generates a Blazor front end backed by a minimal API. The starter template includes a weather forecast endpoint, a counter page, and pre-wired health checks, giving you something functional to explore immediately.

Subsequent prompts walk through the remaining configuration:

Project name:         TinyTicket
Output path:          TinyTicket
Use dev localhost:    Yes
Redis cache:          No
Test project:         No
AI agent environment: No

Tim keeps every optional feature turned off to minimize complexity. The goal is a lean starting point that future episodes will build on incrementally. Once the scaffold completes, open the folder in VS Code and trust the workspace when prompted.

Understanding the Project Structure

[6:42 - 10:00] The generated solution contains four projects, and the relationships between them reveal how Aspire works. The App Host project is the orchestration layer. Its Program.cs is roughly twelve lines of code:

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

Notice how the front end declares a reference to the API and waits for it to become healthy before starting. That dependency ordering, service discovery, and health checking is all Aspire provides at the code level. There is no hidden magic beyond what you see in this file.

Alongside the app host sits the Service Defaults project, which contains extension methods for telemetry, structured logging, and health check registration. These are opt-in conveniences: if you haven't already configured OpenTelemetry or health endpoints in your services, the defaults wire them up for you.

The API Service project has a single endpoint that returns randomly generated weather forecasts. The Web project is a Blazor application that calls the API through an HttpClient configured with just a service name ("api"). Aspire resolves that name to the correct URL at runtime, so the Blazor app never hardcodes a port number or hostname.

Tim highlights an important deployment detail: Aspire itself does not get deployed to production. The orchestration is a development-time tool. In production, the service URLs come from configuration (environment variables, app settings, or a deployment pipeline), and the apps run independently without the app host.

Running and Exploring the Dashboard

[10:59 - 14:46] Launch the app host through the Run and Debug panel in VS Code, selecting the HTTPS launch profile. After the initial restore and build, the Aspire dashboard opens in the browser. The first time you connect, you will need to paste a login token from the terminal output.

The dashboard surfaces four categories of observability data without any additional configuration:

Console output aggregates stdout from every service into a single view. Instead of switching between terminal tabs, you see all output interleaved and filterable by service.

Structured logs display log entries with their structured properties intact. The certificate trust warning Tim encounters, for example, appears here with full context about which service generated it and at what severity level.

Traces show distributed call chains. When the Blazor front end requests weather data, the trace shows the HTTP GET from the front end, the hop to the API service (which took 7.35 milliseconds in the video), and the total page render time. Tim points out that the absolute numbers matter less than the relative comparisons: if a call normally takes 5 seconds and suddenly takes 10, you have found your regression without attaching a profiler.

Metrics provide per-service counters for request rates, error rates, and resource consumption. The dashboard also exposes environment variables and endpoint credentials for each service, which is useful for verifying that configuration values are flowing through correctly.

Introducing Tiny Ticket: The Series Project

[14:46 - 17:17] Tim outlines the plan for the project that will carry through the rest of the series. Tiny Ticket is a stripped-down help desk application: users submit support tickets, and the system tracks priority and status. The data model may be as small as a single SQL table. The point is not to build a feature-rich product but to create a vertical slice that touches every part of the development lifecycle on Linux: building, testing, deploying, and connecting to external services.

The starter template's weather forecast and counter pages will be replaced with ticket views, but the Aspire orchestration, the API-to-frontend pattern, and the service defaults will remain. Future episodes will add Microsoft SQL Server as the database, with Tim addressing a common objection: developers who cannot run SQL Server locally (ARM processors, for example) sometimes reach for a different database. His response is that the development environment should replicate production. If the production database is SQL Server, the dev environment needs to match, even if that means running the database in a container.

Wrapping Up: From Zero to Dashboard

[17:17 - 18:20] In under twenty minutes, the video covers the full Aspire setup on Linux: a CLI install, a VS Code extension, a scaffolded project, and a dashboard that provides structured logging, distributed tracing, and metrics with zero custom configuration. The real value of Aspire is not any single feature but the reduction in friction: one process to launch, one dashboard to monitor, and one place to see how services interact.

Conclusion

[18:20 - 18:53] Setting up Aspire on Linux requires the CLI tool, the VS Code extension, and a project scaffold. From there, the dashboard gives you observability across every service without writing telemetry code. The app host file defines your service graph in a dozen lines, and the service defaults handle the plumbing you would otherwise configure manually.

The Tiny Ticket project introduced here will serve as the foundation for upcoming episodes on database integration, Azure deployment, and cross-platform workflows. Following along from this starting point means each new concept builds on infrastructure you have already verified.

Series navigation: This article is part of the C# on Linux series building the Tiny Ticket app. Previous: SQL Server in Docker on Linux. Next: Adding Swagger UI to .NET Aspire on Linux.

Example Tip: When the VS Code template picker fails to discover Aspire templates after extension installation, use aspire new from the terminal as a reliable fallback, then restart VS Code afterward to sync the extension state.

Watch full video on his YouTube Channel and gain more insights on setting up .NET Aspire for Linux development.