DEV Community: Chris Ayers

NDC Security 2026

Chris Ayers — Sat, 28 Feb 2026 00:00:00 +0000

I’m excited to be speaking at NDC Security 2026 in Oslo, March 2-5! I’ll be presenting MITRE ATT&CK for Developers — showing how developers can go beyond the OWASP Top 10 and use the ATT&CK framework to think like attackers and build stronger defenses.

About NDC Security

NDC Security is a dedicated security conference for software developers, held at the Radisson Blu Scandinavia Hotel in Oslo. With 66 sessions and over 60 speakers, it bridges the gap between development and security — designed for developers who want to build secure software and security professionals who want to understand modern development practices.

This year features an all-new OWASP x NDC Security track, bringing OWASP content directly into the conference lineup.

My Talk: MITRE ATT&CK for Developers

Wednesday, March 4 at 10:20 — Room 3

Most developers know the OWASP Top 10, but fewer know the MITRE ATT&CK framework. In this talk, I’ll cover how ATT&CK complements OWASP, walk through real attack chains with code examples in Python, C#, and JavaScript, and show practical detection patterns you can implement in your applications. The goal: think like an attacker, build like a defender.

For a preview, check out my blog post on MITRE ATT&CK for Developers: Beyond OWASP.

Conference Highlights

Keynote

Michael Howard opens the conference with 25 Years of the Microsoft SDL — a look back at how the Security Development Lifecycle has shaped how we build secure software.

Workshops (March 2-3)

The conference kicks off with two days of hands-on workshops:

Bulletproof APIs: Hands-On API Security — Philippe De Ryck
Hack Yourself First: How to Go on the Cyber-Offence — Scott Helme
Identity and Access Control for Modern Applications using ASP.NET 10 — Anders Abel
Building and Deploying Secure AI: Practical Strategies for Developers — Jim Manico
Attack and Secure AI Apps - Wargame Edition — Davide Cioccia
Full-Stack Pentesting Laboratory — Dawid Czagan

Notable Sessions

A few talks I’m looking forward to:

Prompt Injection Attacks in LLM-Powered Applications — Magno Logan
ASP.NET Core Meets OWASP Top 10 2025 — Anders Abel
Securing Model Context Protocol (MCP) — Jim Manico
Getting Authorization Right in .NET — Michele Leroux Bustamante
Beyond the Commit: Weaponizing and Hardening GitHub Actions — Niek Palm
Your Website Is Running Code You’ve Never Seen — Scott Helme

See You There

If you’re attending NDC Security, come say hello! You can check out the full agenda and grab tickets at ndcsecurity.com.

Promoted to Principal Software Engineer at Microsoft

Chris Ayers — Mon, 23 Feb 2026 00:00:00 +0000

I’m thrilled to share that I’ve been promoted to Principal Software Engineer at Microsoft!

The Journey

It’s been an incredible four and a half years at Microsoft, and this milestone still feels a bit surreal. When I joined Microsoft in October 2021 as a Senior Customer Engineer on the Fast Track for Azure (FTA) team, I was living a dream I’d had since childhood. I never imagined the journey would bring me here.

During my time on the FTA team, I worked directly with customers adopting Azure, helping them architect and build cloud-native solutions. It was an amazing experience - every engagement brought new challenges, new architectures, and new opportunities to learn and teach.

In late 2024, I moved to the Azure Reliability (AzRel) Risk SRE team, a shift that pushed me into entirely new territory. As the lead for the Platform Reliability Pillar, I dove into outage analysis, building AI-driven tooling with OpenAI and Semantic Kernel to help engineers understand failures and strengthen Azure’s reliability at scale. It was a big change, but it reinforced something I’ve always believed - growth comes from stepping into the unfamiliar.

Looking Forward

As a Principal Software Engineer, I’m continuing to focus on Azure reliability - building tools and systems that help keep the platform running smoothly for millions of users worldwide. I’m also doubling down on the things I’m passionate about:

Building - AI-powered tooling for reliability engineering, distributed systems, and cloud-native applications
Speaking - sharing what I’ve learned at conferences around the world, from NDC and Techorama to DevSum and Aspire Conf
Community - organizing DevOps Days Tampa Bay, active with Tampa Devs and multiple local meetups, mentoring, and contributing to open source
Writing - more blog posts, more samples, more sharing

What Does Principal Mean at Microsoft

For those curious about what this level means at Microsoft, I wanted to share some context. At Microsoft, engineering levels form a career ladder, and the jump from Senior to Principal represents a meaningful shift in scope, impact, and expectations.

A Senior Software Engineer (levels 63-64) typically executes complex features, leads projects within a single team, designs components, reviews code, and mentors team members. The focus is largely on the how - delivering high-quality work within established frameworks.

A Principal Software Engineer (levels 65-67) operates differently. The role shifts toward strategic technical leadership - defining architecture across multiple teams, solving organization-wide problems, and aligning technology decisions with business goals. The focus moves to the why - long-term strategy, navigating high ambiguity, and innovating beyond existing solutions.

Some of the key differences:

Scope of Impact - Senior engineers own projects within a team. Principals influence entire organizations, divisions, or large-scale technical strategies
Technical Focus - Principals handle high ambiguity and innovate beyond existing solutions. Seniors work within established frameworks to deliver features
Leadership - Principals guide technical direction, manage stakeholders, and mentor other senior engineers. Seniors focus more on day-to-day implementation and mentoring junior staff

For me, this promotion reflects the way I’ve been working - constantly sharing knowledge, educating the team, and helping set technical direction. Whether it’s building alignment across orgs and teams, driving architecture decisions, or connecting people and ideas across organizational boundaries, the Principal role formalizes what I believe great engineering looks like at scale.

At its core, it comes down to a growth mindset. The willingness to step into ambiguity, learn continuously, and lift others up along the way. That’s what got me here, and it’s what I’ll keep doing.

Gratitude

None of this happens alone. I’m grateful for the incredible teammates and mentors I’ve had on both teams, the managers who championed my growth, and the community that keeps pushing me to learn and share. And of course, my family - who support all the late nights, conference travel, and the constant tinkering.

If you’re on your own career journey, here’s what I’d say: don’t be afraid to take the leap into unfamiliar territory. The skills you’ve built are more transferable than you think, and the best growth happens outside your comfort zone.

Here’s to the next chapter. Let’s build something great.

Aspire CLI Part 3 - MCP for AI Coding Agents

Chris Ayers — Sun, 22 Feb 2026 00:00:00 +0000

In Part 1, we covered creating and running Aspire apps. In Part 2, we explored deployment and CI/CD. Now let’s look at one of Aspire’s most exciting features: MCP (Model Context Protocol) support for AI coding agents.

Aspire MCP enables AI coding agents to understand and interact with your distributed applications. Your AI assistant can query resource states, debug with real-time logs, and investigate telemetry across your entire system — without you having to copy/paste anything.

What is Aspire MCP?

The Aspire MCP server is a local Model Context Protocol server that connects your AI coding assistants to your running distributed application. Starting with Aspire 9.0, MCP support has been available through manual dashboard configuration, and Aspire 13.1 added the aspire mcp init command for automatic setup.

Note: The aspire mcp commands are being renamed to aspire agent in a future release. The generated configs already use aspire agent mcp. See the MCP sample for a complete working example with Postgres, Redis, and pre-configured AI agent support.

It bridges the gap between your running distributed application and AI coding assistants like GitHub Copilot, Claude Code, Cursor, and OpenAI Codex.

With Aspire MCP, your AI assistant can:

Query resources — Get resource states, source, endpoints, health status, and available commands
Debug with logs — Access real-time console logs from any resource
Investigate telemetry — Analyze structured logs and distributed traces across services
Execute commands — Run resource commands directly
Discover integrations — Find and understand available Aspire hosting integrations

This transforms your AI assistant from a code generator into a development partner that understands your running system.

Two Transport Modes

Before setting up MCP, it helps to understand the two transport modes:

STDIO (CLI approach) — The AI assistant launches aspire mcp start as a subprocess. No URL or API key needed. This is the recommended approach for Aspire 13.1+.
HTTP (manual/dashboard approach) — The Aspire dashboard exposes an HTTP endpoint with URL + API key authentication. This is the approach for Aspire 9.0-13.0 or when you need more control.

Getting Started

Option 1: Using the Aspire CLI (Recommended)

Starting with Aspire 13.1, the aspire mcp init command detects supported AI assistant environments and creates the appropriate configuration files:

cd your-aspire-project
aspire mcp init

The command detects supported AI assistants in your environment and generates configuration files. Currently supported assistants for automatic setup:

Visual Studio Code — Generates .vscode/mcp.json
GitHub Copilot CLI — Generates Copilot CLI configuration
Claude Code — Generates .claude/ configuration
OpenCode — Generates OpenCode configuration

The generated config uses STDIO transport, launching aspire mcp start as a subprocess. For example, Visual Studio Code gets a .vscode/mcp.json like:

{
 "servers": {
 "aspire": {
 "type": "stdio",
 "command": "aspire",
 "args": ["mcp", "start"]
 }
 }
}

If you don’t already have an AGENTS.md file in your project, one is created automatically with context about your Aspire application to help AI assistants understand your project.

Option 2: Manual Configuration (Aspire 9.0-13.0)

For older Aspire versions, or when you need more control:

Run your Aspire app with aspire run
Open the Aspire dashboard
Click the MCP button in the top right corner
Use the displayed settings to configure your AI assistant

The dashboard provides these settings for HTTP-based MCP:

Setting	Description
`url`	Aspire MCP endpoint address
`type`	`http` (streamable-HTTP MCP server)
`x-mcp-api-key`	HTTP header for securing access

This approach supports additional assistants including Visual Studio, Cursor, and OpenAI Codex. Consult your tool’s MCP documentation for configuration details.

MCP Tools Available

Once connected, your AI assistant gains access to several powerful tools:

Resource Management

list_resources — Lists all resources with state, health status, source, endpoints, and commands
execute_resource_command — Executes commands on specific resources

Logging and Telemetry

list_console_logs — Gets console logs for a resource
list_structured_logs — Retrieves structured logs, optionally filtered by resource
list_traces — Lists distributed traces, optionally filtered by resource name
list_trace_structured_logs — Gets structured logs for a specific trace

Integration Discovery

list_integrations — Shows available Aspire hosting integrations with package IDs and versions
get_integration_docs — Retrieves documentation for a specific integration package

AppHost Management

list_apphosts — Lists all AppHost connections, showing which are within the working directory scope and which are outside
select_apphost — Switches context to a specific AppHost

Example Prompts

After configuring MCP, try these prompts with your AI assistant:

“Are all my resources running?”
“Show me the last 50 log entries from the API service”
“Analyze HTTP request performance for the webfrontend”
“What traces show errors in the last 5 minutes?”
“Restart unhealthy resources”
“What Aspire integrations are available for Redis?”

Excluding Resources from MCP

You may have resources with sensitive data that shouldn’t be exposed to AI assistants. Annotate them in your AppHost:

var builder = DistributedApplication.CreateBuilder(args);

var apiservice = builder.AddProject<Projects.Api>("api")
 .ExcludeFromMcp(); // This resource hidden from MCP

builder.AddProject<Projects.Web>("web")
 .WithReference(apiservice);

builder.Build().Run();

This excludes the resource and its associated telemetry from all MCP results.

A Practical Example

Consider a polyglot application using the Aspire CLI with AI-assisted development. Here’s a sample AppHost from the Aspire 13 samples:

#:package Aspire.Hosting.OpenAI@13.0.0
#:package Aspire.Hosting.Python@13.0.0
#:package Aspire.Hosting.Docker@13-*
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddDockerComposeEnvironment("dc");

var openai = builder.AddOpenAI("openai");

builder.AddUvicornApp("ai-agent", "./agent", "main:app")
 .WithUv()
 .WithExternalHttpEndpoints()
 .WithEnvironment("OPENAI_API_KEY", openai.Resource.Key);

builder.Build().Run();

After running aspire mcp init and aspire run, you can ask your AI assistant things like:

“Is the ai-agent resource healthy?”
“Show me any errors in the agent logs”
“What OpenTelemetry traces have the longest duration?”

The AI sees the Python service, the OpenAI connection, health check status, logs, and traces — all in real time. No more copying log output into chat windows.

Supported AI Assistants

Assistant	`aspire mcp init`	Manual (Dashboard)	Docs
Visual Studio Code Copilot	✅	✅	MCP servers
GitHub Copilot CLI	✅	✅	Add MCP server
Claude Code	✅	✅	MCP configuration
OpenCode	✅	✅	OpenCode docs
Visual Studio	—	✅	MCP configuration
Cursor	—	✅	Installing MCP servers
OpenAI Codex	—	✅	MCP setup

Securing the API Key

When using the manual/HTTP configuration, the x-mcp-api-key secures access to MCP. Your AI assistant needs access to this key — use your tool’s secure storage to avoid committing it to source control.

Visual Studio Code Example — Use input variables to prompt for the key at connection time rather than hardcoding it in mcp.json.

Note: If you’re using aspire mcp init (STDIO transport), there’s no API key to manage — authentication is handled by the subprocess communication.

Troubleshooting

Self-Signed Certificate Issues

Some AI assistants don’t support self-signed HTTPS certificates. If you encounter connection issues:

If you use the http launch profile, you’re already set
For HTTPS, configure just the MCP endpoint to use HTTP in launchSettings.json:

{
 "profiles": {
 "https": {
 "environmentVariables": {
 "ASPIRE_DASHBOARD_MCP_ENDPOINT_URL": "http://localhost:16036",
 "ASPIRE_ALLOW_UNSECURED_TRANSPORT": "true"
 }
 }
 }
}

Caution : This removes transport security from MCP communication.

Data Size Limits

AI models have context limits. Aspire MCP automatically:

Truncates large data fields (like exception stack traces)
Omits older items from large telemetry collections

Why This Matters

Traditional AI coding assistants work with static code. Aspire MCP connects them to your running system. This enables scenarios like:

“Why is the checkout service slow?” - The AI can analyze traces and identify the bottleneck
“Debug this 500 error” - The AI accesses structured logs to find the root cause
“Is my database connection healthy?” - The AI checks resource health status directly

Instead of asking you to describe your system, the AI can observe it directly.

Learn More

Wrapping Up

Aspire MCP represents a shift in how we interact with distributed applications during development. By giving AI assistants real-time access to your running system, you unlock debugging and development workflows that weren’t possible before.

Try aspire mcp init in your next project and see how it transforms your AI-assisted development experience.

Until next time, happy Aspiring!

Aspire CLI Part 2 - Deployment and Pipelines

Chris Ayers — Sat, 21 Feb 2026 00:00:00 +0000

In Part 1, we covered the basics of the Aspire CLI: creating projects with aspire new, adding Aspire to existing apps with aspire init, running with aspire run, and managing integrations with aspire add and aspire update. Now let’s dive into deployment and CI/CD pipelines.

Prerequisite: Aspire 13 requires .NET SDK 10.0.100 or later. Make sure you have it installed before using the commands in this post.

The Publish and Deploy Model

Aspire separates deployment into two distinct phases:

Publish (aspire publish) — Generates intermediate, parameterized deployment artifacts (Compose files, Kubernetes manifests, Bicep templates, etc.)
Deploy (aspire deploy) — Resolves parameters and applies those artifacts to a target environment

This separation is intentional. Published assets contain placeholders instead of concrete values — secrets and environment-specific configuration are injected later at deploy time. This keeps sensitive data out of your artifacts and enables the same published output to target multiple environments.

`aspire publish` - Generate Deployment Artifacts

The aspire publish command generates deployment artifacts based on the compute environments configured in your AppHost. A compute environment represents a target platform and determines what gets generated.

aspire publish -o ./artifacts

The output depends on which hosting integration packages you’ve added:

NuGet Package	Target	Publish	Deploy
`Aspire.Hosting.Docker`	Docker Compose	✅ Yes	🧪 Preview
`Aspire.Hosting.Kubernetes`	Kubernetes	✅ Yes	🧪 Preview
`Aspire.Hosting.Azure.AppContainers`	Azure Container Apps	✅ Yes	✅ Yes (Preview)
`Aspire.Hosting.Azure.AppService`	Azure App Service	✅ Yes	✅ Yes (Preview)

If no integration supports publishing, aspire publish will tell you:

No resources in the distributed application model support publishing.

Parameterized Output

Published artifacts contain placeholders rather than concrete values. For example, a Docker Compose publish might generate:

services:
 pg:
 image: "docker.io/library/postgres:17.2"
 environment:
 POSTGRES_PASSWORD: "${PG_PASSWORD}"
 ports:
 - "8000:5432"
 api:
 image: "${API_IMAGE}"
 environment:
 ConnectionStrings__db: "Host=pg;Port=5432;Username=postgres;Password=${PG_PASSWORD};Database=db"

Notice ${PG_PASSWORD} and ${API_IMAGE} are not resolved during publish. You supply their values at deploy time — through environment variables, .env files, or CI/CD pipeline secrets.

Docker Compose Example

The most common pattern from the Aspire samples uses Docker Compose as the compute environment. See the Docker Compose sample for a complete working example.

#:package Aspire.Hosting.Docker@13-*
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddDockerComposeEnvironment("dc");

var postgres = builder.AddPostgres("postgres")
 .WithDataVolume()
 .WithPgAdmin();
var db = postgres.AddDatabase("db");

builder.AddCSharpApp("api", "./api")
 .WithHttpHealthCheck("/health")
 .WithExternalHttpEndpoints()
 .WaitFor(db)
 .WithReference(db);

builder.Build().Run();

Then the standard workflow is:

aspire run # Run locally
aspire publish -o ./artifacts # Generate Docker Compose files
aspire deploy # Deploy to Docker Compose
aspire do docker-compose-down-dc # Tear down the deployment

Azure Container Apps Example

For Azure, add the Azure Container Apps environment. See the Azure Container Apps sample for a complete working example.

#:package Aspire.Hosting.Azure.AppContainers@13.0.0
#:package Aspire.Hosting.Azure.Storage@13.0.0
#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

builder.AddAzureContainerAppEnvironment("env");

var storage = builder.AddAzureStorage("storage")
 .RunAsEmulator();

var blobs = storage.AddBlobContainer("images");

builder.AddProject<Projects.Api>("api")
 .WithExternalHttpEndpoints()
 .WithReference(blobs);

builder.Build().Run();

Publishing this generates Bicep templates that you can review, customize, and deploy:

aspire publish -o ./azure-artifacts # Generates Bicep files
aspire deploy # Deploys to Azure Container Apps

Kubernetes Example

For Kubernetes, add the hosting package and configure a compute environment. See the Kubernetes sample for a complete working example.

var builder = DistributedApplication.CreateBuilder(args);

var k8s = builder.AddKubernetesEnvironment("k8s");

var api = builder.AddProject<Projects.Api>("api")
 .WithExternalHttpEndpoints();

builder.Build().Run();

Generate and deploy:

# Generate Kubernetes manifests
aspire publish -o ./k8s-output

# Apply with kubectl or Helm
kubectl apply -f ./k8s-output

Multiple Compute Environments

If you add multiple compute environments, Aspire needs to know which resource goes where. Use WithComputeEnvironment to disambiguate:

var k8s = builder.AddKubernetesEnvironment("k8s-env");
var compose = builder.AddDockerComposeEnvironment("docker-env");

builder.AddProject<Projects.Frontend>("frontend")
 .WithComputeEnvironment(k8s);

builder.AddProject<Projects.Backend>("backend")
 .WithComputeEnvironment(compose);

Without this, Aspire throws an ambiguous environment exception at publish time.

`aspire deploy` - Deploy to a Target

The aspire deploy command resolves parameters and applies published artifacts to a target environment. This command is in preview and under active development.

aspire deploy

Note: The deploy command may change as it matures. Keep an eye on the .NET Blog and the Aspire deployment docs for updates.

What happens depends on your compute environment:

Docker Compose — Builds images, resolves variables, runs docker compose up
Azure Container Apps — Provisions Azure resources, builds and pushes container images, deploys apps
Kubernetes — Generates manifests and applies them

For Docker Compose deployments, the workflow from the official samples is straightforward:

aspire run # Run locally
aspire deploy # Deploy to Docker Compose
aspire do docker-compose-down-dc # Teardown

For Azure deployments, aspire deploy prompts for:

Azure sign-in and subscription selection
Resource group creation or selection
Location for Azure resources

The command then provisions infrastructure, builds containers, pushes to ACR, and deploys — all in one step.

For non-interactive deployment (CI/CD), set these environment variables to skip the prompts:

Azure__SubscriptionId=<your-subscription-id>
Azure__Location=<azure-region>
Azure__ResourceGroup=<resource-group-name>

`aspire do` - Pipeline Automation

The aspire do command executes pipeline steps defined by hosting integrations. Use aspire do diagnostics to discover what steps are available and their dependencies:

# List available pipeline steps
aspire do diagnostics

# Tear down a Docker Compose deployment
aspire do docker-compose-down-dc

# The naming convention is: docker-compose-down-{environment-name}

Well-known pipeline steps include build, push, publish, and deploy. Resources can contribute custom steps — for example, Docker Compose adds teardown steps. This command is particularly useful in CI/CD pipelines and for managing environment lifecycle.

`aspire exec` - Run Commands in Resource Context

The aspire exec command runs commands in the context of a specific resource with the correct connection strings and environment variables. This command is disabled by default — enable it first. See the exec sample for a complete working example with Postgres and Redis.

# Enable the exec feature
aspire config set features.execCommandEnabled true

Then use the --resource (or -r) flag to specify the target:

# Run EF Core migrations
aspire exec --resource mydb -- dotnet ef database update

# Open an interactive shell in a container
aspire exec --resource redis -- redis-cli

# Start a dependency and then run against it
aspire exec --start-resource mydb -- dotnet ef migrations add Init

The --start-resource (or -s) flag is useful when you need to start a resource (and its dependencies) before running a command against it.

Azure Developer CLI (azd) Integration

For production Azure deployments, the Azure Developer CLI (azd) has first-class Aspire support and is the more mature deployment path:

# Initialize azd in your project directory
azd init

# Provision infrastructure and deploy in one command
azd up

During azd init, you’ll:

Select which services to expose to the internet
Name your environment (e.g., dev, prod)
Choose your Azure subscription and location

The azd up command handles the full lifecycle: azd package → azd provision → azd deploy. Projects are packaged into containers, Azure resources are provisioned via Bicep, and containers are pushed to Azure Container Registry and deployed to Container Apps.

Generated files:

azure.yaml — Maps Aspire AppHost services to Azure resources
.azure/config.json — Active environment configuration
.azure/{env}/.env — Environment-specific overrides
.azure/{env}/config.json — Public endpoint configuration

GitHub Actions

Using azd (Recommended for Azure)

name: Deploy Aspire App

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '10.0.x'

 - name: Install azd
 uses: Azure/setup-azd@v2

 - name: Log in to Azure
 uses: azure/login@v2
 with:
 creds: ${{ secrets.AZURE_CREDENTIALS }}

 - name: Provision and Deploy
 run: azd up --no-prompt
 env:
 AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
 AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
 AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}

Using Aspire CLI

name: Deploy with Aspire CLI

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - name: Setup .NET
 uses: actions/setup-dotnet@v4
 with:
 dotnet-version: '10.0.x'

 - name: Install Aspire CLI
 run: curl -fsSL https://aspire.dev/install.sh | bash

 - name: Publish artifacts
 run: aspire publish -o ./artifacts
 working-directory: ./src/MyApp.AppHost

 - name: Deploy with Docker Compose
 run: |
 cd ./artifacts
 docker compose up --build -d

Legacy Manifest Format

Starting with Aspire 9.2, the single deployment manifest is being phased out in favor of the aspire publish / aspire deploy model with hosting integration extensibility. The legacy manifest is still available for debugging:

aspire do publish-manifest --output-path ./diagnostics

This produces a manifest snapshot for inspecting resource graphs and troubleshooting, but it’s not the primary deployment path.

Learn More

Wrapping Up

The publish/deploy model gives you flexibility: publish generates parameterized artifacts, and deploy resolves values and applies them. Whether you’re targeting Docker Compose for local staging, Kubernetes for container orchestration, or Azure Container Apps for managed hosting, the workflow is consistent.

For production Azure deployments, I recommend azd for its mature infrastructure-as-code capabilities. For Docker Compose and local deployment workflows, aspire deploy is increasingly capable as it matures.

In Part 3, we explore one of Aspire’s most exciting features: MCP (Model Context Protocol) integration, which lets AI coding agents like GitHub Copilot and Claude understand and interact with your running Aspire applications.

Until next time, happy Aspiring!

Migrating from Jekyll to Hugo Part 3: Deployment and Lessons Learned

Chris Ayers — Sun, 25 Jan 2026 00:00:00 +0000

In the final part of this series, I cover deploying Hugo to GitHub Pages and share the challenges I encountered.

GitHub Actions Workflow

Here’s the workflow I use to deploy Hugo to GitHub Pages:

name: Deploy Hugo site to Pages

on:
 push:
 branches: [main]
 workflow_dispatch:

permissions:
 contents: read

concurrency:
 group: "pages"
 cancel-in-progress: true

jobs:
 build:
 runs-on: ubuntu-latest
 permissions:
 contents: read
 pages: write
 id-token: write
 env:
 HUGO_VERSION: 0.154.5
 steps:
 - name: Checkout
 uses: actions/checkout@8e8c483db84b4bee # v6.0.2
 with:
 fetch-depth: 0
 persist-credentials: false
 submodules: recursive

 - name: Setup Hugo
 uses: peaceiris/actions-hugo@75d2e847 # v3.0.0
 with:
 hugo-version: ${{ env.HUGO_VERSION }}
 extended: true

 - name: Setup Pages
 id: pages
 uses: actions/configure-pages@983d7736 # v5.0.0

 - name: Cache Hugo resources
 uses: actions/cache@8b402f58 # v5.0.3
 with:
 path: |
 ${{ runner.temp }}/hugo_cache
 resources/_gen
 key: hugo-${{ runner.os }}-${{ hashFiles('content/ **', 'config/**', 'assets/**') }}
 restore-keys: |
 hugo-${{ runner.os }}-

 - name: Build with Hugo
 env:
 HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
 HUGO_ENVIRONMENT: production
 TZ: America/New_York
 run: |
 hugo \
 --gc \
 --minify \
 --baseURL "${{ steps.pages.outputs.base_url }}/"

 - name: Upload artifact
 uses: actions/upload-pages-artifact@7b1f4a76 # v4.0.0
 with:
 path: ./public

 deploy:
 needs: build
 runs-on: ubuntu-latest
 permissions:
 pages: write
 id-token: write
 environment:
 name: github-pages
 url: ${{ steps.deployment.outputs.page_url }}
 steps:
 - name: Deploy to GitHub Pages
 id: deployment
 uses: actions/deploy-pages@d6db9016 # v4.0.5

Key points:

SHA-pinned actions - Every action is pinned to a commit SHA, not a mutable tag — critical for supply chain security
Scoped permissions - Minimal permissions declared per-job, not at the workflow level
submodules: recursive - Required for the theme submodule
fetch-depth: 0 - Needed for .GitInfo and .Lastmod
persist-credentials: false - Security best practice for checkout
Pinned Hugo version - HUGO_VERSION env var ensures reproducible builds
Caching - Both hugo_cache and resources/_gen are cached to speed up builds
--gc --minify - Clean up unused cache entries and optimize output

Linting with Super-Linter

In addition to the deploy workflow, I added a Super-Linter workflow that runs on every PR:

name: Super-Linter

on:
 pull_request: null

concurrency:
 group: ${{ github.workflow }}-${{ github.ref }}
 cancel-in-progress: true

jobs:
 build:
 name: Lint
 runs-on: ubuntu-latest
 permissions:
 contents: read
 packages: read
 statuses: write
 steps:
 - name: Checkout code
 uses: actions/checkout@8e8c483db84b4bee # v6.0.1
 with:
 fetch-depth: 0
 persist-credentials: false

 - name: Super-linter
 uses: super-linter/super-linter@d5b0a2ab # v8.3.2
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 VALIDATE_ALL_CODEBASE: 'false'
 # Auto-fix formatting on PR
 FIX_CSS_PRETTIER: 'true'
 FIX_HTML_PRETTIER: 'true'
 FIX_JSON_PRETTIER: 'true'
 FIX_MARKDOWN_PRETTIER: 'true'
 FIX_YAML_PRETTIER: 'true'
 # Disable linters that don't apply
 VALIDATE_JSCPD: 'false'
 VALIDATE_PYTHON: 'false'
 # Use repo markdownlint config
 MARKDOWN_CONFIG_FILE: '.markdownlint.yml'
 # Don't lint the theme submodule
 FILTER_REGEX_EXCLUDE: 'themes/.*'

This catches markdown issues, YAML errors, and formatting problems before they hit main. The FIX_* options automatically commit formatting corrections back to the PR branch, which saves a lot of manual cleanup. I exclude the themes/ directory since that’s third-party code.

I also keep linting config files in the repo root:

.markdownlint.yml - Disables rules like MD013 (line length) and MD033 (inline HTML — needed for Hugo shortcodes)
.yaml-lint.yml - Warns on formatting issues without blocking
.textlintrc - Terminology checks
.eslintrc.yml - JavaScript linting for any custom scripts

Challenges and Solutions

Challenge 1: Preserving URLs

Jekyll and Hugo generate different URL structures. To avoid breaking existing links, I used Hugo aliases:

# In front matter
aliases:
 - /category/development/my-old-post-url/

For bulk redirects, I created static/_redirects for Netlify-style redirects (works with some hosts).

Challenge 2: Theme Version Compatibility

I hit this warning early on:

WARN Module "blowfish" is not compatible with this Hugo version

Solution : Pin both Hugo and theme versions:

# In GitHub Actions
env:
 HUGO_VERSION: 0.154.5

# Pin theme to specific tag
cd themes/blowfish
git checkout v2.97.0

Challenge 3: Date Formatting

Hugo uses Go’s reference time format. This tripped me up — Go doesn’t use YYYY-MM-DD style format strings. Instead, it uses a specific reference time:

Go reference time: Mon Jan 2 15:04:05 MST 2006

So in Hugo templates, you format dates like this:

{{/* Long date */}}
{{ .Date.Format "January 2, 2006" }}
{{/* Output: January 25, 2026 */}}

{{/* ISO date */}}
{{ .Date.Format "2006-01-02" }}
{{/* Output: 2026-01-25 */}}

{{/* With time */}}
{{ .Date.Format "Jan 2, 2006 3:04 PM" }}
{{/* Output: Jan 25, 2026 12:00 AM */}}

The magic is that every component of the format is a specific number: month=1, day=2, hour=3, minute=4, second=5, year=6, timezone=7 (MST). Once you internalize that, it clicks.

Challenge 4: Custom Layouts

Some Jekyll layouts needed recreation. Hugo’s template lookup order:

layouts/<type>/<layout>.html
layouts/_default/<layout>.html
Theme equivalents

I started by copying theme layouts to my layouts/ folder and customizing.

Challenge 5: Split Config Files

Hugo supports splitting configuration across multiple files. Rather than one monolithic config.toml, I use a config/_default/ directory:

config/_default/
├── hugo.toml # Core site settings
├── languages.en.toml
├── markup.toml # Goldmark, syntax highlighting
├── menus.en.toml
├── module.toml
└── params.toml # Theme parameters

This keeps things organized — especially as Blowfish has many configurable params. One thing that helped: setting buildFuture = true in hugo.toml so scheduled posts show up locally during development.

Challenge 6: RSS Feed URLs

Jekyll’s feed was at /feed.xml, but Hugo defaults to /index.xml. To avoid breaking existing subscribers, I configured Hugo to output both:

# hugo.toml
[outputs]
 home = ["HTML", "RSS", "FEED", "JSON"]

# Legacy feed.xml for backward compatibility with Jekyll
[outputFormats.FEED]
 mediaType = "application/rss+xml"
 baseName = "feed"

The custom FEED output format needs a matching template, so I copied the theme’s rss.xml into my layouts:

cp themes/blowfish/layouts/_default/rss.xml layouts/_default/feed.xml

Now both /index.xml and /feed.xml are generated — existing subscribers keep working, and Hugo’s default feed works too.

Tips for Your Migration

Start fresh - Create new Hugo site, don’t convert in place
Migrate incrementally - Move posts in batches, test as you go
Use hugo server -D - Shows drafts with hot reload
Read theme docs - Blowfish has excellent documentation
Test all pages - Especially taxonomy and archive pages
Check mobile - Verify responsive design works
Validate feeds - Test RSS/Atom with a feed reader

Before and After

Metric	Jekyll	Hugo
Build time	30+ seconds	< 1 second
Dependencies	Ruby, Bundler, gems	Single binary
Hot reload	Slow	Instant
Theme options	Limited	Extensive

Conclusion

The migration took a weekend of focused work, but it was absolutely worth it. Hugo’s speed and flexibility have made maintaining this blog much more enjoyable.

The key is taking it step by step:

Set up Hugo with your chosen theme
Migrate content in batches
Fix shortcodes and assets
Set up deployment
Test thoroughly before switching DNS

If you’re considering the switch, I hope this series helps. Feel free to reach out with questions!

Resources

Migrating from Jekyll to Hugo Part 2: Content Migration

Chris Ayers — Sun, 18 Jan 2026 00:00:00 +0000

In Part 1, I covered why I switched from Jekyll to Hugo. Now let's dive into the actual content migration.

Front Matter Conversion

Most Jekyll posts work with minimal changes, but there are key differences:

# Jekyll
---
layout: post
title: "My Post"
date: 2024-01-15
categories: development
tags: [docker, containers]
mermaid: true
---

# Hugo
---
title: "My Post"
date: 2024-01-15
categories:
  - Development
tags:
  - Docker
  - Containers
---

Key changes I made:

Removed layout: post - Hugo infers layout from content location
Converted tags/categories to arrays - YAML list format
Standardized capitalization - Consistent taxonomy naming
Removed mermaid: true - Blowfish auto-detects mermaid shortcodes

{{< alert "lightbulb" >}}
Tip: Run hugo server while migrating so you can preview each converted post immediately and catch front matter issues early.
{{< /alert >}}

Shortcode Conversions

Jekyll uses Liquid templates while Hugo has its own shortcode system.

Images and Figures

<!-- Jekyll -->
{% include figure.html src="/images/photo.jpg" caption="My caption" %}

<!-- Hugo -->
{{</* figure src="/images/photo.jpg" caption="My caption" */>}}

Here's the Hugo figure shortcode in action:

{{< figure src="images/logos/hugo-logo.svg" alt="Hugo Logo" caption="The Hugo logo rendered with the figure shortcode" class="mx-auto" width="200" >}}

Code Blocks

Standard fenced code blocks work the same, but Hugo adds features:

<!-- Hugo with line numbers -->
{{</* highlight go "linenos=table,hl_lines=3" */>}}
func main() {
    fmt.Println("Hello")
    fmt.Println("Highlighted!")
}
{{</* /highlight */>}}

Here's what that looks like rendered with Hugo's syntax highlighting and line numbers:

{{< highlight go "linenos=table,hl_lines=3" >}}
func main() {
fmt.Println("Hello")
fmt.Println("Highlighted!")
}
{{< /highlight >}}

Mermaid Diagrams

This was a bigger change. Jekyll with the mermaid plugin uses fenced code blocks:



<!-- Jekyll -->


```mermaid
graph TD
    A --> B
```

Hugo with Blowfish requires the mermaid shortcode:



<!-- Hugo -->
{{</* mermaid */>}}
graph TD
    A --> B
{{</* /mermaid */>}}

I wrote a quick script to find and convert these across all posts. Here's what a real mermaid diagram looks like after migration:

{{< mermaid >}}
flowchart LR
A["Jekyll Post\n(.md + Liquid)"] -->|migrate| B["Hugo Post\n(.md + Shortcodes)"]
B --> C{"hugo build"}
C --> D["Static HTML"]
C --> E["Processed Images"]
C --> F["Minified CSS/JS"]
{{< /mermaid >}}

Static Assets

Jekyll and Hugo organize assets differently:

Jekyll	Hugo
`assets/images/`	`static/images/`
`_data/`	`data/`
`_includes/`	`layouts/partials/`

For images referenced in posts, I kept paths like /images/photo.jpg which maps to static/images/photo.jpg.

{{< alert >}}
Watch out: Hugo's assets/ folder is for files processed by Hugo Pipes (SCSS, image resizing, fingerprinting). Use static/ for files served as-is. Mixing them up leads to 404s.
{{< /alert >}}

Handling Excerpts

Jekyll uses excerpt_separator in config or  in posts. Hugo works the same way with :

---
title: "My Post"
---

This appears in the summary.

<!--more-->

This is the full content.

Taxonomy Cleanup

I took the opportunity to consolidate tags:

Merged similar tags (vscode → VSCode)
Standardized capitalization
Removed unused categories

Bulk Migration Script

"The best migration is the one you automate. Don't hand-edit 60 posts when a script can do it in seconds."

For 60+ posts, I used a simple PowerShell script:

Get-ChildItem "content/posts/*.md" | ForEach-Object {
    $content = Get-Content $_.FullName -Raw

    # Remove layout: post
    $content = $content -replace "layout: post\r?\n", ""

    # Remove mermaid: true
    $content = $content -replace "mermaid: true\r?\n", ""

    Set-Content $_.FullName $content
}

{{< alert "circle-info" >}}
Note: The PowerShell script above covers the basics, but you may need additional passes for things like Liquid raw/endraw blocks or custom Jekyll includes. Test thoroughly!
{{< /alert >}}

What's Next

In Part 3, I'll cover deployment with GitHub Actions and the challenges I encountered along the way.

Resources

Migrating from Jekyll to Hugo Part 1: Why I Made the Switch

Chris Ayers — Sun, 11 Jan 2026 00:00:00 +0000

After years of running this blog on Jekyll, I finally made the switch to Hugo. Here’s why.

Why I Made the Switch

Static site generators have evolved a lot since Jekyll first popularized the idea of building blogs from Markdown. Jekyll served me well for a long time, but as my site grew and my workflow matured, a few pain points became impossible to ignore:

Build times : As my site grew, Jekyll builds slowed to a crawl. Waiting 30+ seconds for a rebuild made local development feel sluggish.
Ruby dependencies : Managing Ruby versions, gems, and Bundler across machines and CI environments was a recurring frustration.
Theme flexibility : I wanted a more modern design system, better dark mode support, and a theme ecosystem that felt alive.

Hugo promised faster builds, a single binary with no external dependencies, and a more modern templating system. Once I started experimenting, the difference was immediate.

Why Hugo Is a Better Fit

Fast builds

Hugo compiles entire sites in milliseconds, and the dev server hot reload feels instant. That alone dramatically improves the writing and editing experience.

No dependency headaches

Hugo is just one binary. No Ruby, no Bundler, no gem conflicts, no version juggling. It works the same on every machine and every CI pipeline.

A more powerful templating system

Hugo’s Go-based templating is far more flexible than Liquid. It supports:

Rich built-in functions
Complex content structures
Custom taxonomies
Shortcodes
Image processing
Multilingual content

Many things that require plugins in Jekyll are built directly into Hugo.

A modern ecosystem

Hugo’s theme community is active, innovative, and built around modern tooling. This is where Blowfish really shines.

Choosing a Theme

I settled on the Blowfish theme for several reasons. Honestly, it is one of the best examples of what Hugo makes possible.

Clean, modern design

Blowfish looks great out of the box, with thoughtful typography, spacing, and layout options.

Dark mode support

Automatic dark and light mode, user-selectable themes, and customizable color palettes are all built in.

Feature-rich components

Blowfish includes components like:

Callouts
Cards
Tabs
Accordions
Grids
Footnotes
Copy-to-clipboard code blocks

These let you build richer content without custom HTML.

Built-in image optimization

Thanks to Hugo’s image pipeline, Blowfish can automatically resize, crop, optimize, lazy-load, and serve responsive images. This is something Jekyll cannot match without external tooling.

Taxonomies and structure

Categories, tags, sections, menus, and breadcrumbs work cleanly and consistently.

Active development and documentation

Blowfish is well maintained, well documented, and constantly improving.

Tailwind CSS for customization

If you want to tweak the design, Tailwind makes it straightforward.

Jekyll vs. Hugo (with Blowfish): A Practical Comparison

Feature / Area	Jekyll	Hugo (with Blowfish)
Build Speed	Slow on larger sites; rebuilds often 20-60 seconds	Extremely fast; rebuilds typically under 1 second
Dependencies	Requires Ruby, Bundler, gems, and version management	Single binary, no external dependencies
Templating System	Liquid (simple but limited)	Go templates (powerful, flexible, feature-rich)
Image Processing	Not built in; requires external tools or plugins	Native image pipeline: resize, crop, optimize, responsive images
Theme Ecosystem	Many themes, but many feel dated or unmaintained	Modern themes with active development; Blowfish is a standout
Dark Mode Support	Theme-dependent; often limited	Built-in automatic dark/light mode plus user theme switching
Content Components	Limited; requires plugins or custom HTML	Blowfish includes cards, callouts, tabs, accordions, grids, and more
Search	Requires external JS libraries or plugins	Blowfish includes fast, built-in client-side search
Multilingual Support	Plugin-based, inconsistent	First-class multilingual support built into Hugo
Taxonomies	Basic categories/tags	Flexible taxonomies, sections, menus, breadcrumbs
Asset Pipeline	Basic; often requires plugins	Built-in minification, fingerprinting, and processing
Customization	Varies by theme; often requires manual CSS	Blowfish uses Tailwind for easy, modern customization
Documentation	Good but plugin-heavy	Excellent docs; Blowfish has strong theme documentation
Local Development	Slower reloads; can feel laggy	Instant hot reload; smooth editing experience
CI/CD	Slower builds; Ruby setup required	Fast builds; no setup beyond Hugo binary
Learning Curve	Easy to start, harder to extend	Easy to start, powerful as you grow

Results

After migrating, a few wins stood out:

Build time : Dropped from 30+ seconds to under 1 second
No dependencies : Just the Hugo binary, nothing else
Better DX : Hot reload is nearly instant
Modern design : Blowfish looks great on all devices
More flexibility : Shortcodes, components, and image processing make content creation easier

Overall, the site feels faster, cleaner, and more maintainable.

What’s Next

In Part 2, I’ll cover the actual migration process:

Converting posts
Fixing front matter
Replacing Jekyll shortcodes
Handling images and static assets
Structuring content for Hugo’s taxonomy system

If you’re considering making the switch yourself, the migration is easier than you might think.

Resources

Getting Started with the Aspire CLI - A Complete Guide

Chris Ayers — Thu, 11 Dec 2025 00:00:00 +0000

This blog was posted as part of the C# Advent Calendar 2025. Make sure to check out everyone else’s work when you’re done here

The Aspire CLI is a cross-platform tool for creating, managing, and running polyglot Aspire projects. This post covers the core commands you’ll use day-to-day.

What is Aspire?

Aspire is an opinionated, cloud-ready stack for building observable distributed applications. Think: a C# AppHost that models your topology, plus integrations and tooling.

Polyglot by Design

While Aspire started in the .NET ecosystem, Aspire 13.0 made Python and JavaScript first-class citizens.

.NET projects - ASP.NET Core APIs, Blazor apps, Worker Services, Azure Functions
Python applications - Flask, FastAPI, Django, or any Python script
JavaScript/Node.js apps - Express, Next.js, or any Node.js application
Containers - Any Docker image you need

The AppHost (orchestrator) is written in C#, but it can coordinate services written in any language.

That said, .NET remains the sweet spot for Aspire because you get the richest integration and tooling.

The Problem Aspire Solves

Coordinating multiple services usually means lots of config, hardcoded URLs, and fragile startup order. Aspire helps by giving you:

Orchestration - Model resources and dependencies in code
Integrations - Standard components for common infrastructure
Tooling - A dashboard + CLI to run and debug the system

Dashboards and Telemetry

Aspire includes a local dashboard that helps you understand what’s running: resource status, endpoints, logs, traces, and metrics.

Telemetry is typically emitted via OpenTelemetry (the ServiceDefaults project wires a lot of this up for .NET services). By default this is a local developer experience. Data only goes to an external backend if you configure an exporter to send it there.

The AppHost: Your Application’s Control Plane

At the heart of every Aspire application is the AppHost. It defines resources and dependencies (and can include health checks and external endpoints).

var builder = DistributedApplication.CreateBuilder(args);

// TODO: Add resources here

builder.Build().Run();

ServiceDefaults: Shared Configuration

The ServiceDefaults project is a shared library for observability and resilience (health checks, OpenTelemetry, logging, etc.).

Each service references ServiceDefaults and calls two methods:

var builder = WebApplication.CreateBuilder(args);
builder.AddServiceDefaults();

var app = builder.Build();
app.MapDefaultEndpoints();
app.Run();

This ensures consistent observability across all services without duplicating configuration.

Aspire vs Docker Compose

If you’re currently using Docker Compose, here’s the mental model shift.

Docker Compose:

services:
 postgres:
 image: postgres:latest

 api:
 build: ./api
 depends_on:
 - postgres

 web:
 build: ./web
 depends_on:
 - api

Aspire equivalent:

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres")
 .AddDatabase("mydb");

var api = builder.AddProject<Projects.Api>("api")
 .WithReference(postgres);

var web = builder.AddProject<Projects.Web>("web")
 .WithReference(api)
 .WaitFor(api);

builder.Build().Run();

Why Aspire often feels better:

Less config glue - Model topology in code
Service discovery by default - Fewer hardcoded URLs
Built-in dashboard - Logs, traces, and metrics in one place
Integrations - Common infra with sensible defaults
Polyglot - C#, Python, JavaScript, containers

Why the Aspire CLI?

The Aspire CLI helps you scaffold, run, and evolve an Aspire application without a pile of scripts and config.

What you’ll use it for:

Create or Aspireify a solution
Run the apphost and open the dashboard
Add integrations and keep packages current

Key takeaways:

aspire new for greenfield projects with full scaffolding
aspire init to add Aspire to existing solutions incrementally
aspire run for development with the built-in dashboard
aspire add to easily integrate databases, caches, and queues
aspire update to keep packages current

Prerequisites

Before installing the Aspire CLI, ensure you have the following:

Requirement	Details
.NET 8+ SDK	Required for Aspire 13.0+. Run `dotnet --info` to verify. The CLI needs the SDK even if your apps target .NET 8 or 9.
Editor/IDE	Visual Studio Code with C# Dev Kit and Aspire extensions, Visual Studio 2022 17.13+, or JetBrains Rider.
Optional	GitHub Codespaces or Dev Containers for cloud-based development.

Installing the Aspire CLI

The install scripts download the CLI and add it to your PATH.

Platform	Install command
Windows (PowerShell)	`irm https://aspire.dev/install.ps1
macOS and Linux (Bash)	{% raw %}`curl -fsSL https://aspire.dev/install.sh

If {% raw %}aspire isn’t found, open a new terminal and try again.

Core CLI Commands

The Aspire CLI provides several commands for different stages of the development lifecycle. Here’s a practical rundown of the core commands.

`aspire new` - Create a New Solution

Use aspire new for greenfield projects.

Basic usage:

# Interactive mode - prompts for template, name, and output
aspire new

# Non-interactive with explicit options
aspire new aspire-starter -n AspireApp -o AspireApp

What gets created:

AspireApp/
├── AspireApp.sln
├── AspireApp.AppHost/ # Dev-time orchestrator
│ ├── AppHost.cs
│ └── AspireApp.AppHost.csproj
├── AspireApp.ServiceDefaults/ # Shared configuration
│ ├── Extensions.cs
│ └── AspireApp.ServiceDefaults.csproj
├── AspireApp.ApiService/ # Mock weather data API
│ ├── Program.cs
│ └── AspireApp.ApiService.csproj
└── AspireApp.Web/ # Blazor frontend
 ├── Program.cs
 └── AspireApp.Web.csproj

You get an AppHost, ServiceDefaults, and a small starter app you can run immediately.

`aspire init` - Add Aspire to Existing Apps

Already have a codebase? aspire init adds an AppHost so you can orchestrate what you already have (including Python and JavaScript).

# Navigate to your solution directory
cd /path/to/your-solution

# Initialize Aspire support
aspire init

The command runs in interactive mode and will create apphost.cs plus minimal run configuration.

After running aspire init:

Your project root gets a file-based AppHost:

my-saas-app/
 apphost.cs # (new) orchestration code
 apphost.run.json # (new) local run configuration
 api/
 main.py
 pyproject.toml
 frontend/
 app.py
 requirements.txt
 worker/
 worker.py
 requirements.txt

The initial apphost.cs is minimal:

#:sdk Aspire.AppHost.Sdk@13.0.0

var builder = DistributedApplication.CreateBuilder(args);

// TODO: Add resources here

builder.Build().Run();

Example: reference a Python API from a Python worker

If you’re orchestrating Python services, add the Python hosting integration to your AppHost:

aspire add python

Then wire resources in the AppHost using AddUvicornApp (for FastAPI, Flask, and other ASGI apps) and AddPythonApp for a worker. WithReference(...) declares the dependency and Aspire injects the connection info as environment variables.

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddUvicornApp("api", "./api", "main:app")
 .WithUv()
 .WithHttpHealthCheck("/health");

var worker = builder.AddPythonApp("worker", "./worker", "worker.py")
 .WithUv()
 .WithReference(api); // Worker gets API_HTTP and API_HTTPS env vars

builder.Build().Run();

`aspire new` vs `aspire init`

Scenario	Command	Why
Starting fresh with a new project	`aspire new`	Scaffolds everything: solution, AppHost, ServiceDefaults, sample projects
Adding Aspire to existing code	`aspire init`	Preserves your existing projects, adds only orchestration layer
Polyglot app (C#, Python, JS)	`aspire init`	Works with existing multi-language repos
Learning Aspire	`aspire new`	Get a working example immediately

`aspire run` - Run the Distributed App

aspire run builds and starts your resources and opens the dashboard.

# From your solution directory
aspire run

What happens:

Finds the AppHost
Builds and starts resources
Prints the dashboard URL

Example output:

Dashboard: https://localhost:17068/login?t=ea559845d54cea66b837dc0ff33c3bd3
Logs: ~/.aspire/cli/logs/apphost-13024-2025-10-31-19-40-58.log

A note on the dashboard and telemetry

The dashboard is where you’ll see status, logs, traces, and metrics for the running app.

`aspire add` - Add Integrations

aspire add adds official integration packages to your AppHost.

# Interactive mode - shows list of available integrations
aspire add

# Add a specific integration by name
aspire add redis

After adding an integration, wire it in your AppHost:

var builder = DistributedApplication.CreateBuilder(args);

// Add Redis resource
var cache = builder.AddRedis("cache");

// Share Redis with your API
var api = builder.AddProject<Projects.YourApi>("api")
 .WithReference(cache)
 .WithHttpHealthCheck("/health");

builder.Build().Run();

Then add the client library to your consuming project:

dotnet add YourApi package Aspire.StackExchange.Redis

Then configure the client in your service (for example, builder.AddRedisClient("cache")).

`aspire update` - Update Packages and Templates

The aspire update command keeps your Aspire projects current by detecting and updating outdated packages and templates.

aspire update

If you want to update the CLI itself (instead of just your solution packages), use:

aspire update --self

Practical Workflow

Here’s a typical workflow for a new project:

# 1. Create a new solution
aspire new

# 2. Run it
aspire run

# 3. Add an integration
aspire add redis

# 4. Update packages (and optionally the CLI)
aspire update
aspire update --self

Learn More

Wrapping Up

There is too much to cover here, so check out the follow-up posts on deployment and AI-assisted development:

Part 2 - Deployment and Pipelines — aspire publish, aspire deploy, and CI/CD with GitHub Actions
Part 3 - MCP for AI Coding Agents — Connect AI assistants to your running Aspire applications

Until next time, happy Aspiring!

Building a Flexible AI Provider Strategy in .NET Aspire

Chris Ayers — Sun, 06 Jul 2025 00:00:00 +0000

How I architected a single codebase to seamlessly switch between Azure OpenAI, GitHub Models, Ollama, and Foundry Local without touching the API service

When building my latest .NET Aspire application, I faced a common challenge: how do you develop and test with different AI providers without constantly rewriting your API service? The answer turned out to be surprisingly elegant - a configuration-driven approach that lets you switch between four different AI providers with zero code changes.

The Problem: A Wide Variety of AI Choices

Modern AI development presents us with a wide variety of options. You might want to:

Develop locally with Ollama for offline work
Prototype quickly with Microsoft’s Foundry Local
Test cheaply with GitHub Models’ free tier
Deploy to production with Azure OpenAI’s enterprise features

The traditional approach would be to write separate implementations for each provider, but that leads to code duplication and maintenance headaches. Instead, I built a system that treats AI providers as interchangeable services.

The Solution: Configuration-Driven Architecture

The key insight was to abstract the AI provider selection entirely out of the API service. Here’s how it works:

{
 "AI": {
 "Provider": "foundrylocal",
 "DeploymentName": "chat",
 "Model": "phi-3.5-mini"
 }
}

That’s it. Change a few lines in your configuration, or swap configurations/environments and your entire application switches AI providers. The result is a seamless transition with no code changes, recompilation, or deployment complexities.

The Four Pillars of AI Provider Flexibility

Provider	Best Use Case	Free Tier	Hardware Needs	Deployment
Azure OpenAI	Production workloads	No	N/A (Cloud)	Cloud
GitHub Models	Prototyping & Testing	Yes (Generous)	N/A (Cloud)	Cloud
Ollama	Offline & Local Dev	Yes	Local CPU/GPU	Local
Foundry Local	Offline High-Perf Local Dev	Yes	Local CPU/GPU	Local

1. Azure OpenAI - The Enterprise Choice

Azure OpenAI is my go-to for production workloads. It’s reliable, scalable, and integrates seamlessly with Azure’s ecosystem:

{
 "AI": {
 "Provider": "azureopenai",
 "Model": "gpt-4o"
 }
}

Why I choose Azure OpenAI for production:

Enterprise SLAs and support
Built-in compliance and security features
Seamless integration with Azure services
Predictable pricing and billing

2. GitHub Models - The Developer’s Friend

GitHub Models surprised me with its generous free tier and extensive model catalog. Based on community feedback and my own testing, it’s proven reliable for development and staging environments.

{
 "AI": {
 "Provider": "githubmodels",
 "Model": "gpt-4o-mini"
 }
}

Perfect for:

Early development and prototyping
Testing different models without cost commitment
Open source projects with budget constraints
Experimenting with cutting-edge models

3. Ollama - The Privacy Champion

For local development and sensitive workloads, Ollama can’t be beat:

{
 "AI": {
 "Provider": "ollama",
 "Model": "llama3.2"
 }
}

When I reach for Ollama:

Working on airplanes or in poor connectivity
Handling sensitive data that can’t leave the premises
Developing features without API costs
Testing with models that aren’t available elsewhere

Mac Performance Note: If you’re on Apple Silicon, avoid running Ollama in Docker containers. Docker on Mac cannot access the Metal GPU due to Apple’s virtualization framework limitations. Instead, install Ollama natively on macOS to take advantage of Metal GPU acceleration. This gives you significantly better performance compared to CPU-only Docker containers. The CommunityToolkit’s Ollama Integration defaults to docker, though you can use a connection string to point it to a native Ollama installation.

4. Foundry Local - The Microsoft Stack Choice

Microsoft’s Foundry Local offers the best of both worlds - local deployment with enterprise-grade models:

{
 "AI": {
 "Provider": "foundrylocal",
 "Model": "phi-3.5-mini"
 }
}

Foundry Local shines when:

Local deployment is required but you want recent models
You’re already invested in the Microsoft AI ecosystem
You want to leverage hardware acceleration on your machine

My Personal Favorite: After testing all four providers extensively, Foundry Local running on-device has become my go-to choice for local AI development. Unlike Ollama in Docker, Foundry Local takes full advantage of your hardware - whether that’s Apple Silicon’s Metal GPU, NVIDIA cards, or CPU optimization. The performance is consistently excellent, and it handles the complexity of hardware acceleration automatically.

The Architecture Behind the Magic

The beauty of this approach lies in its simplicity. The API service never knows which AI provider it’s using-it just calls the abstracted AI service interface. This is all made possible by the Microsoft.Extensions.AI library, which provides the core IChatClient abstraction. The complete source code for this project is available on my GitHub.


%%{init: {'theme': 'default'}}%%
graph TD
 subgraph title[Configuration-Driven AI Provider Architecture]
 A[appsettings.json] --> B{AI Provider Config};
 B --> C{AddAIServices};
 C --> D{IChatClient};
 subgraph API Service
 D --> E[Your Service Code];
 end
 subgraph Provider Implementations
 C --> F[AzureOpenAIClient];
 C --> G[OllamaApiClient];
 C --> H[GitHubModels Client];
 C --> I[FoundryLocal Client];
 end
 end

Here’s how I structured it.

The Secret Sauce: Configuration-Driven Service Registration

The magic happens in the AIServiceExtensions.cs file. A single call in Program.cs kicks everything off:

// In your Program.cs
var builder = WebApplication.CreateBuilder(args);

// This one line does it all
builder.AddAIServices();

The AddAIServices extension method reads the configuration and registers the correct IChatClient implementation. At its heart is a simple switch statement that delegates to a specific registration method for each provider:

public static IHostApplicationBuilder AddAIServices(this IHostApplicationBuilder builder)
{
 var aiSettings = AIConfiguration.GetSettings(builder.Configuration);
 builder.Services.AddSingleton(aiSettings);

 switch (aiSettings.Provider)
 {
 case AIProvider.Ollama:
 builder.AddOllamaAIServices(aiSettings);
 break;
 case AIProvider.AzureOpenAI:
 builder.AddAzureOpenAIServices(aiSettings);
 break;
 case AIProvider.GitHubModels:
 builder.AddGitHubModelsAIServices(aiSettings);
 break;
 case AIProvider.FoundryLocal:
 builder.AddFoundryLocalAIServices(aiSettings);
 break;
 default:
 throw new InvalidOperationException($"Unsupported AI provider: {aiSettings.Provider}");
 }
 return builder;
}

Provider-Specific Implementations

Each provider has a slightly different setup.

Azure OpenAI and Ollama

For Azure OpenAI and Ollama, the setup is straightforward thanks to .NET Aspire’s built-in support. A single line is enough to register the client:

private static void AddAzureOpenAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 builder.AddAzureOpenAIClient("ai-service")
 .AddChatClient(aiSettings.DeploymentName);
}

private static void AddOllamaAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 builder.AddOllamaApiClient(aiSettings.DeploymentName)
 .AddChatClient();
}

GitHub Models and Foundry Local

GitHub Models and Foundry Local require a bit more manual configuration. They both use the standard OpenAIClient but pointed at different endpoints.

For GitHub Models, we create an OpenAIClient pointing to the models.inference.ai.azure.com endpoint:

private static void AddGitHubModelsAIServices(this IHostApplicationBuilder builder, AISettings aiSettings)
{
 var githubToken = builder.Configuration["GITHUB_TOKEN"] ??
 builder.Configuration["ConnectionStrings:GitHubModels"];

 builder.Services.AddSingleton<IChatClient>(serviceProvider =>
 {
 var openAIClient = new OpenAIClient(
 new System.ClientModel.ApiKeyCredential(githubToken),
 new OpenAIClientOptions { Endpoint = new Uri("https://models.inference.ai.azure.com") }
 );
 return openAIClient.GetChatClient(aiSettings.Model).AsIChatClient();
 });
}

For Foundry Local, the code first starts the local model server using FoundryLocalManager and then creates an OpenAIClient that points to the local endpoint it provides.

private static void AddFoundryLocalAIServices(this IHostApplicationBuilder builder, AIConfiguration.AISettings aiSettings)
{
 builder.Services.AddSingleton<IChatClient>(serviceProvider =>
 {
 var manager = FoundryLocalManager.StartModelAsync(aliasOrModelId: aiSettings.Model).GetAwaiter().GetResult();
 var modelInfo = manager.GetModelInfoAsync(aliasOrModelId: aiSettings.Model).GetAwaiter().GetResult();

 var openAIClient = new OpenAIClient(
 new System.ClientModel.ApiKeyCredential(manager.ApiKey),
 new OpenAIClientOptions { Endpoint = manager.Endpoint }
 );
 return openAIClient.GetChatClient(modelInfo?.ModelId ?? aiSettings.Model).AsIChatClient();
 });
}

Your API service code remains blissfully unaware of this complexity. It simply requests an IChatClient and starts making calls, confident that the correct provider is handling the request.

Real-World Switching Techniques

Technique 1: Environment-Based Switching

My favorite approach is to use environment-specific configuration files:

// appsettings.Development.json
{
 "AI": {
 "Provider": "foundrylocal",
 "Model": "phi-3.5-mini"
 }
}

// appsettings.Production.json
{
 "AI": {
 "Provider": "azureopenai",
 "Model": "gpt-4o"
 }
}

This means developers get fast, local AI by default, while production gets the reliability of Azure OpenAI.

Technique 2: Feature Flag-Style Switching

Want to test a new provider with just a subset of users? Environment variables make this trivial:

# Test GitHub Models for 10% of traffic
export AI__Provider="githubmodels"
export AI__Model="gpt-4o-mini"

Technique 3: Command-Line Override

Perfect for debugging or one-off tests:

dotnet run --project src/BuildWithAspire.AppHost -- --AI:Provider=ollama --AI:Model=llama3.2

Building for Resilience: Error Handling and Health Checks

A flexible provider strategy also requires robust error handling. What happens if your primary provider goes down or a local model crashes?

I recommend implementing a few key patterns:

Health Checks : Use .NET Aspire’s health check features to monitor the status of your AI provider endpoints. This allows you to detect failures quickly and potentially route traffic away from an unhealthy provider.
Retry Policies : Implement a retry policy (e.g., with Polly) to handle transient network issues.
Fallback Strategy : For critical applications, consider a fallback mechanism. If a request to your primary provider fails, you could automatically retry with a secondary provider. This can be implemented within a custom IChatClient wrapper.

These strategies ensure your application remains resilient, even when individual components fail.

Lessons Learned from Production

What Works Well

GitHub Models exceeded my expectations. The free tier is generous, and the model selection is impressive. I’ve been using it for all my development work, and it’s become my go-to for prototyping.

Ollama is fantastic for air-gapped environments. When I need to demo on a flight or work with sensitive data, Ollama ensures I’m never blocked by connectivity issues.

Foundry Local surprised me with its performance. While I haven’t run formal benchmarks, my experience shows that first-token response times are significantly faster with Foundry Local on my machine compared to cloud-based providers. It’s become my default choice for local AI development.

What Caught Me Off Guard

Token usage varies dramatically between providers. The same conversation might cost 10x more on one provider than another. I learned to monitor token usage carefully, especially when switching between providers.

Model behavior isn’t always consistent. GPT-4o on Azure OpenAI behaves slightly differently than on GitHub Models. It’s not a problem, but it’s worth testing your specific use cases when switching.

Local providers need warm-up time. Ollama and Foundry Local can take a few seconds to respond to the first request after being idle. I added a simple warm-up call during application startup.

Mac users, beware the Docker trap. I learned this the hard way: running Ollama in Docker on Apple Silicon is painfully slow because Docker can’t access the Metal GPU. Apple’s virtualization framework blocks GPU exposure to containers, so you get CPU-only performance. The solution? Run Ollama natively or use Foundry Local on macOS for Metal acceleration.

The Cost-Optimization Strategy

Here’s how I use different providers throughout my development lifecycle:

Development: Foundry Local or Ollama (free, fast iteration)
Testing: GitHub Models (free tier covers most testing needs)
Staging: GitHub Models or Azure OpenAI (depending on expected load)
Production: Azure OpenAI (enterprise features, SLAs)

This approach has cut my AI development costs by roughly 80% while maintaining flexibility.

The One-Line Provider Switch

The most satisfying part of this architecture is how easy it is to switch providers. Whether you’re responding to a service outage, testing a new model, or optimizing costs, it’s always just a simple configuration change or command line override.

No code changes. No redeployment. Just a quick update and restart.

A Note on Versioning

The AI landscape is evolving rapidly. For this project, I used .NET 9 with .NET Aspire 9.3. If you’re implementing a similar solution, be sure to check for the latest versions and any potential breaking changes.

What’s Next?

I’m excited about the future of AI provider flexibility. Some ideas I’m exploring:

Intelligent routing based on request type or user tier
Cost-based switching that automatically chooses the most economical provider
A/B testing different models for the same conversation
Hybrid approaches that use multiple providers for different parts of the same workflow

The configuration-driven approach makes all of these possibilities simple to implement.

Final Thoughts

Building AI applications doesn’t have to lock you into a single provider. With the right architecture, you can have the best of all worlds: local development, cost-effective testing, and enterprise-grade production deployment.

The key is to think of AI providers as interchangeable services from day one. Your future self will thank you when you need to switch providers for cost, performance, or compliance reasons.

Have you built something similar? I’d love to hear about your experiences with multi-provider AI architectures. Drop me a line on Blue Sky or LinkedIn.

Headless CMS on GitHub Pages

Chris Ayers — Thu, 26 Jun 2025 00:00:00 +0000

Headless CMS on GitHub Pages

I’ve been running my site on GitHub Pages - no server, just git and GitHub Actions. But I still want a CMS that works on mobile, without dragging around a laptop or doing a Git clone. Enter Sveltia CMS + Sveltia CMS Auth on Cloudflare Workers. Here’s how to glue it together.

Why This Setup?

No paid services like Netlify.
I edit blog posts from my phone-even waiting in line for coffee.
No git install, no desktop.

A solution exists: Sveltia’s Cloudflare Workers-based authenticator makes GitHub-backed CMS possible on GitHub Pages.

🎯 Step 1: Add Sveltia CMS to Your Site

In your /admin/index.html, include Sveltia, a lightweight, modern CMS:

<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="robots" content="noindex" />
    <title>Content Manager</title>
</head>

<body>
    <script src="https://unpkg.com/@sveltia/cms/dist/sveltia-cms.js"></script>
</body>

</html>

No heavy JS, no React-just Svelte. Touch support, dark mode, fast. It handles GitHub directly via your browser or the auth worker.

🔐 Step 2: Deploy the Sveltia-CMS-Auth Worker

Fork or import sveltia-cms-auth into Cloudflare Workers.
Deploy it; grab the Worker URL.
Register a GitHub OAuth App, using the Worker URL plus /callback for the redirect.
Add client credentials and your domain to Workers environment variables. Deploy again.

Now your site has its own auth client-it communicates with GitHub when you click Login.

🛠 Step 3: Wire It All Up in Your Config

In your Sveltia admin/config.yml, under backend:

backend:
  name: github
  repo: <OWNER>/<REPO> # Path to your GitHub repository
  # optional, defaults to master
  branch: main
  base_url: https://<WORKER>.workers.dev
# This line should *not* be indented
media_folder: "assets/uploads" # Media files will be stored in the repo under images/uploads

That base_url points Sveltia’s OAuth to your Worker. Push the change, and your /admin/ loads Sveltia. Clicking “Login” redirects to GitHub via your Worker, and you’re ready to edit.

📱 Step 4: Edit From Your Phone

Visit yourgithubpages.com/admin/ on your mobile device. The UI is responsive and built for touch. I’ve easily edited blog posts without needing VS Code or Terminal. Sveltia handles commit and push transparently.

Quick FAQ

Q: Why not Decap CMS or Netlify CMS?

A: They typically rely on external OAuth providers. Sveltia + Cloudflare Workers solves that neatly.

Q: Does it require a PC?

A: Only initial setup needs a desktop. Afterward, your CMS runs entirely in-browser, even mobile.

Q: Self-hosted?

A: GitHub Pages hosts the static site. The CMS runs client-side, and auth is on Cloudflare’s free tier.

TL;DR

Goal	Tool
GitHub-only hosting	GitHub Pages (no server)
Modern, touch-ready UI	Sveltia CMS
OAuth via GitHub	Sveltia-CMS-Auth Worker
Zero laptop edits	Fully mobile browser-compatible

This combo gives me a mobile-friendly CMS experience without extra hassle. If you’re editing your Jekyll-based GitHub Pages blog without a PC, this setup hits the mark.

Related Resources

Understanding AI and Prompting Techniques Part 1

Chris Ayers — Sun, 25 May 2025 00:00:00 +0000

Understanding AI and Prompting Techniques Part 1

Artificial Intelligence (AI) has rapidly evolved from science fiction to an integral part of our daily lives, transforming how we interact with technology and reshaping industries worldwide. Whether you’re using ChatGPT to draft emails, asking Copilot to write code, or generating images with DALL-E, understanding how to effectively communicate with AI systems has become an essential skill.

In this first part of our series, we’ll explore foundational concepts of AI, machine learning, deep learning, and generative AI, then dive deep into the art of prompting—the key to unlocking AI’s full potential.

What is AI?
Key AI Terms
AI Models
Tokens: The Language of AI
Prompting
What’s Next?

What is AI?

Artificial Intelligence is a branch of computer science dedicated to creating intelligent machines capable of performing tasks that typically require human intelligence. These tasks include problem-solving, decision-making, language understanding, and perception.

Evolution of AI

AI has evolved through distinct phases, each building upon the previous:

1950s - Artificial Intelligence : The foundational era where pioneers like Alan Turing and John McCarthy laid the groundwork for machines that could simulate human reasoning and problem-solving.
1980s-1990s - Expert Systems : Rule-based systems that captured human expertise in specific domains, marking the first practical AI applications.
1997 - Machine Learning Breakthrough : IBM’s Deep Blue defeated world chess champion Garry Kasparov, showcasing the power of algorithms that could learn and improve.
2012 - Deep Learning Revolution : The ImageNet competition demonstrated that neural networks with multiple layers could dramatically outperform traditional methods in image recognition.
2017 - Transformer Architecture : The introduction of the “Attention Is All You Need” paper revolutionized natural language processing, leading to modern AI models.
2022-2024 - Generative AI Explosion : Models like ChatGPT, GPT-4, and Claude brought AI to mainstream audiences, enabling creation of text, images, code, and more from simple prompts.

Key AI Terms

To effectively engage with AI, it’s essential to understand some fundamental terms.

AI Models

AI models are the engines that power modern artificial intelligence. A model is a system trained on large datasets to recognize patterns, make predictions, or generate new content. The quality and capabilities of an AI system depend heavily on the underlying model.

How Models Work

Training : Models are trained using vast amounts of data and advanced algorithms.
Learning Patterns : Through training, models learn to identify trends, relationships, and structures in data.
Making Predictions : Once trained, models can process new data to make predictions, classify information, or generate content.

Popular AI Models (2025)

Company/Organization	Model	Specialization	Key Features
OpenAI	GPT-4o, GPT-4o mini, o1	Language, reasoning	Advanced reasoning, multimodal capabilities
Microsoft	Phi-4, Copilot	Code, productivity	Optimized for efficiency, integrated tools
Anthropic	Claude 3.5 Sonnet, Claude 3.5 Haiku	Conversational AI	Constitutional AI, safety-focused
Meta	Llama 3.1, Llama 3.2	Open-source language	Available for research and commercial use
Google	Gemini Pro, Gemini Ultra	Multimodal AI	Strong integration with Google services
DeepSeek	DeepSeek-R1	Reasoning	Specialized in logical reasoning tasks

These models differ significantly in their architecture, training data, and intended use cases. For example:

GPT-4o excels at complex reasoning and multimodal tasks (text, images, audio)
Claude 3.5 Sonnet is known for its helpful, harmless, and honest responses
Phi-4 is optimized for efficiency while maintaining strong performance
Llama 3.1 offers powerful open-source alternatives for developers

“The choice of model determines the capabilities and limitations of your AI-powered application.”

Tokens: The Language of AI

Tokens are the fundamental units that AI models use to process and understand language. Think of tokens as the “words” in AI’s vocabulary, though they don’t always correspond directly to human words.

Understanding Tokenization

When you submit text to an AI model, it first breaks your input into tokens through a process called tokenization. Here’s what you need to know:

Size : One token roughly equals 4 characters of English text
Conversion : 100 tokens ≈ 75 English words
Variability : Common words might be single tokens, while rare words or technical terms might be split into multiple tokens
Languages : Different languages have different tokenization patterns (e.g., Chinese characters often require more tokens per word)

Why Tokens Matter

Understanding tokens helps you:

Optimize prompts : Stay within model token limits
Manage costs : Many AI services charge per token
Improve efficiency : Craft concise prompts that convey maximum information

Token Limits in Practice

Most AI models have token limits for both input and output:

GPT-4o : Up to 128,000 input tokens
Claude 3.5 Sonnet : Up to 200,000 input tokens
Gemini Pro : Up to 1,000,000 input tokens

Pro Tip : Use online token counters to estimate your prompt length before submitting to AI models, especially for complex tasks or long documents.

Prompting

Prompting is the art of communicating with AI models to achieve useful and relevant responses. The effectiveness of a prompt depends on clarity, context, and the role you assign to the model. Well-crafted prompts can dramatically improve the quality and relevance of AI outputs.

Why Prompting Matters

Clear prompts reduce ambiguity and help the model understand your intent.
Providing context ensures the AI tailors its response to your needs.
Assigning roles guides the model’s tone, expertise, and style.

Components of a Good Prompt

Component	Description	Example
Instruction	What you want the AI to do	Summarize this article in 3 sentences.
Context	Background or specifics	The article is about renewable energy trends in 2025.
Role	Persona or expertise	You are an energy policy analyst.
Format	Desired output style	Respond in bullet points.
Constraints	Limits or requirements	Use no more than 100 words.

Practical Prompting Tips

Be specific : Vague prompts lead to vague answers. Specify what you want.
Add context : Include relevant details, such as audience, purpose, or scenario.
Set a role : Tell the AI who it should act as for more targeted responses.
Request a format : Ask for lists, tables, or summaries if needed.
Iterate : Refine your prompt if the output is not what you expect.

Prompting Examples

Without context:

“Write an email inviting people to a meeting.”

With context and role:

“You are a project manager at Contoso. Write a formal email inviting the Azure Reliability team to a kickoff meeting next Thursday at 2 PM ET to discuss outage analysis improvements using AI.”

The second prompt produces a much more targeted and useful response because it provides:

Role clarity : Project manager perspective
Specific context : Company name, team, meeting purpose
Clear details : Date, time, topic
Tone guidance : Formal communication

The Power of Context and Roles

Why Context Matters

Context provides the background information that transforms generic AI responses into tailored, relevant outputs:

Audience awareness : Specify who will read/use the output (executives, developers, students)
Purpose clarity : Define what you want to achieve (inform, persuade, educate, troubleshoot)
Constraints : Include relevant limitations (time, budget, technical requirements)
Domain specifics : Provide industry or technical context when needed

Effective Role Assignment

Assigning roles gives the AI a persona and expertise focus:

Professional roles : “You are a cybersecurity expert,” “Act as a technical architect,” “Respond as a UX designer”
Communication styles : “Explain like I’m 5,” “Use formal business language,” “Write in a conversational tone”
Perspective shifts : “From a customer’s viewpoint,” “Consider the developer experience,” “Think like a project manager”

Example of role impact:

Generic prompt: “How do I optimize this SQL query?”

Role-specific prompt: “You are a senior database administrator. Review this SQL query for a high-traffic e-commerce site and suggest optimizations that prioritize read performance while maintaining data consistency.”

Advanced Prompting Techniques

Beyond the basics, here are some powerful techniques for getting better results:

Chain of Thought Prompting

Ask the AI to “think step by step” or “show your reasoning”:

Analyze this code for security vulnerabilities. Think step by step:
1. First, identify potential input validation issues
2. Then, check for authentication and authorization flaws
3. Finally, look for data exposure risks

Few-Shot Learning

Provide examples of the desired output format:

Convert these technical terms to plain English:

API → Application Programming Interface (a way for software to communicate)
SDK → Software Development Kit (tools for building apps)
Docker → [Your task: explain this term]

Prompt Chaining

Break complex tasks into smaller, sequential prompts:

“Summarize this 50-page document into key themes”
“For each theme, identify 3 actionable recommendations”
“Create a presentation outline based on these recommendations”

Understanding AI Model Limitations

While AI models are powerful, it’s crucial to understand their limitations:

Statelessness and Memory

Most AI models are stateless—they don’t remember previous interactions unless explicitly provided with conversation history. Each request is independent, which means:

No persistent memory : The model won’t remember what you discussed earlier unless you include it in your current prompt
Context windows : Models can only “see” a limited amount of text at once (their context window)
Application responsibility : Chat applications maintain conversation history and send it with each new request

Other Key Limitations

Knowledge cutoffs : Models are trained on data up to a specific date and don’t know about events after that
Hallucinations : Models may generate plausible-sounding but incorrect information
Bias : Training data biases can influence model outputs
Reasoning limitations : While improving, models can struggle with complex logical reasoning

Best Practice : Always verify important information from AI models, especially for critical decisions or factual claims.

“Effective prompting combines clear instructions, relevant context, and well-defined roles to guide AI models toward your desired outcome.”

What’s Next?

In this series, we’ll dive deeper into advanced prompt engineering techniques, including:

Prompt patterns and templates for common use cases
Multi-modal prompting with images, audio, and code
Prompt optimization strategies for better performance
Real-world case studies from software development, content creation, and data analysis
Safety and ethical considerations in AI prompting

Whether you’re a developer looking to integrate AI into your applications, a content creator exploring AI-assisted workflows, or simply curious about maximizing your productivity with AI tools, the next part will provide practical techniques you can apply immediately.

“Mastering AI prompting is like learning a new language—the better you communicate, the more powerful the results.”

Stay tuned for Part 2, where we’ll put these concepts into practice with hands-on examples and advanced strategies!

Aspiring .NET & Resilience @ NDC Oslo 2025

Chris Ayers — Sat, 24 May 2025 00:00:00 +0000

As I’m flying from Oslo to Amsterdam, I’m still buzzing with energy and inspiration from NDC Oslo 2025. It was an incredible week of learning, sharing, and connecting with some of the brightest minds in technology. From thought-provoking keynotes that challenged our assumptions to the epic The Linebreakers concert at Brewgata, every moment reinforced why each NDC conference but NDC Oslo remains one of the premier developer conferences in the world.

A Journey of Learning and Sharing

NDC Oslo 2025 brought together over 2,000 developers, architects, and technology leaders from across the globe. The conference’s unique blend of deep technical content and community spirit created an atmosphere where learning happened not just in sessions, but in every conversation.

As a speaker at this year’s event, I had the privilege of presenting two sessions that reflect the current evolution of our industry:

Aspiring .NET with Azure OpenAI and Ollama

During the Community Days event, I showcased practical AI integration patterns for .NET developers:

Building semantic search capabilities using Azure OpenAI embeddings
Running local LLMs with Ollama for development and testing
Implementing responsible AI practices including content filtering and rate limiting
Creating conversational interfaces that enhance rather than replace existing applications

The recently updated samples for .NET Aspire 9.3 sparked discussions about the future of AI in enterprise applications.

Resilient by Design

In this session, I explored how to build systems that don’t just survive failure-they thrive despite it. We dove into:

Chaos engineering principles and how to implement them safely in production
Circuit breaker patterns with real-world examples from Azure deployments
Graceful degradation strategies that maintain user experience during partial outages
Observability practices that make resilience measurable and improvable

The engaged room had questions demonstrated just how critical resilience has become in our cloud-native world.

Engaging with Diverse Perspectives

What makes NDC Oslo special is its commitment to showcasing the full spectrum of modern technology. This year’s program delivered exceptional content across multiple tracks:

AI and Machine Learning

Beyond the hype, speakers demonstrated practical AI implementations that solve real business problems. Sessions ranged from building RAG (Retrieval-Augmented Generation) systems to implementing ethical AI governance frameworks.

Cloud Architecture

The cloud track featured battle-tested patterns for building distributed systems at scale. Highlights included:

Event-driven architectures using Azure Service Bus and Event Grid
Multi-region deployment strategies with zero-downtime deployments
Cost optimization techniques that saved companies millions

Developer Experience

A refreshing focus on making developers’ lives better, with sessions covering:

Modern debugging techniques for distributed systems
AI-powered code review tools
Creating effective development environments with DevContainers

Performance and Optimization

Deep technical dives into making applications faster and more efficient:

.NET performance improvements and how to leverage them
Database query optimization strategies
Frontend performance patterns for modern SPAs

Security and Best Practices

Critical discussions on protecting modern applications:

Zero-trust architecture implementation
Supply chain security for containerized applications
OWASP Top 10 for cloud-native applications

Psychology and Soft Skills

Perhaps the most impactful track, addressing the human side of technology:

Building psychologically safe teams
Managing technical debt without burnout
Effective communication strategies for technical leaders

Conference Highlights

Keynotes That Inspired

Laila Bougria’s “CTRL+SHIFT+(BUILD) PAUSE” was a masterclass in presentation excellence. Her exploration of using AI in our daily workflow and the importance of not giving way too much control resonated deeply. The way she wove personal stories with technical insights created a narrative that was both educational and emotionally compelling.

David Whitney’s “The Unbearable Weight of Architecture” challenged us to think beyond technical perfection. His emphasis on pragmatic architecture decisions and the importance of designing with intentionality struck a chord with the audience. His discussion of how wrong decisions cast long shadows over systems-dooming maintainers to endless toil-was both sobering and enlightening.

Rendle’s closing keynote “Reasons To Be Cheerful: 0, 1, 2…” sent us home with renewed optimism. His journey through technology’s evolution reminded us how far we’ve come and painted an exciting picture of where we’re heading.

Beyond the Sessions

The true magic of NDC Oslo happened between the scheduled talks:

Coffee Conversations : Where a casual chat about microservices turned into a deep dive on event sourcing
Lightning Talks : 10-minute bursts of inspiration that often packed more value than hour-long sessions
Workshop Deep Dives : Hands-on learning that transformed theory into practice

The Legendary NDC Party

The conference’s social highlight deserves special mention. The evening began with fascinating presentations on space technology (who knew satellite communication could be so entertaining?), followed by a nostalgic journey through the Demo Scene that had everyone reminiscing about their first coding experiences.

The Phil Nash Karaoke session was legendary-complete with a full chorus of developers providing hyena sound effects for “Be Prepared” from The Lion King. It perfectly captured the conference’s spirit: serious about technology, but never taking ourselves too seriously.

Key Takeaways

Reflecting on NDC Oslo 2025, several themes emerged that will shape my work in the coming year:

AI Integration is Now Table Stakes The question is no longer whether to integrate AI, but how to do it responsibly and effectively. Every application can benefit from intelligent features, but success requires thoughtful implementation and clear value propositions.
Resilience Through Simplicity The most resilient systems aren’t necessarily the most complex. Sessions repeatedly emphasized that simple, well-understood patterns often outperform clever solutions when things go wrong.
Community Amplifies Individual Impact The connections made at NDC Oslo will generate more value than any single session. The mix of experienced architects sharing war stories with eager newcomers created a learning environment that benefits everyone.
Practical Beats Theoretical The most successful sessions focused on “here’s how we actually did it” rather than “here’s how it should work in theory.” Real-world case studies and live coding demonstrations drove the most engagement.
The Human Element Remains Central Despite all our technological advances, the sessions on team dynamics, communication, and mental health drew the largest crowds. Technology is ultimately about people, and NDC Oslo never forgot that.

Looking Ahead

The conversations started at NDC Oslo will continue through blog posts, open-source contributions, and community meetups.

For those considering attending future NDC events, I cannot recommend them highly enough. Whether you’re a seasoned architect or just starting your development journey, you’ll find sessions, workshops, and conversations that challenge and inspire you.

The technology landscape continues to evolve at breakneck speed, but events like NDC Oslo remind us that we’re not navigating these changes alone. We’re part of a global community of builders, thinkers, and problem-solvers, all working to create a better technological future.

Thank you, NDC Oslo, for another unforgettable experience. See you next year!

DEV Community: Chris Ayers

NDC Security 2026

About NDC Security

My Talk: MITRE ATT&CK for Developers

Conference Highlights

Keynote

Workshops (March 2-3)

Notable Sessions

See You There

Promoted to Principal Software Engineer at Microsoft

The Journey

Looking Forward

What Does Principal Mean at Microsoft

Gratitude

Aspire CLI Part 3 - MCP for AI Coding Agents

What is Aspire MCP?

Two Transport Modes

Getting Started

Option 1: Using the Aspire CLI (Recommended)

Option 2: Manual Configuration (Aspire 9.0-13.0)

MCP Tools Available

Resource Management

Logging and Telemetry

Integration Discovery

AppHost Management

Example Prompts

Excluding Resources from MCP

A Practical Example

Supported AI Assistants

Securing the API Key

Troubleshooting

Self-Signed Certificate Issues

Data Size Limits

Why This Matters

Learn More

Wrapping Up

Related Posts

Aspire CLI Part 2 - Deployment and Pipelines

The Publish and Deploy Model

aspire publish - Generate Deployment Artifacts

Parameterized Output

Docker Compose Example

Azure Container Apps Example

Kubernetes Example

Multiple Compute Environments

aspire deploy - Deploy to a Target

aspire do - Pipeline Automation

aspire exec - Run Commands in Resource Context

Azure Developer CLI (azd) Integration

GitHub Actions

Using azd (Recommended for Azure)

Using Aspire CLI

Legacy Manifest Format

Learn More

Wrapping Up

Related Posts

Migrating from Jekyll to Hugo Part 3: Deployment and Lessons Learned

GitHub Actions Workflow

Linting with Super-Linter

Challenges and Solutions

Challenge 1: Preserving URLs

Challenge 2: Theme Version Compatibility

Challenge 3: Date Formatting

Challenge 4: Custom Layouts

Challenge 5: Split Config Files

Challenge 6: RSS Feed URLs

Tips for Your Migration

Before and After

Conclusion

Resources

Migrating from Jekyll to Hugo Part 2: Content Migration

Front Matter Conversion

Shortcode Conversions

Images and Figures

Code Blocks

Mermaid Diagrams

Static Assets

Handling Excerpts

Taxonomy Cleanup

Bulk Migration Script

`aspire publish` - Generate Deployment Artifacts

`aspire deploy` - Deploy to a Target

`aspire do` - Pipeline Automation

`aspire exec` - Run Commands in Resource Context

`aspire new` - Create a New Solution

`aspire init` - Add Aspire to Existing Apps

`aspire new` vs `aspire init`

`aspire run` - Run the Distributed App

`aspire add` - Add Integrations

`aspire update` - Update Packages and Templates