DEV Community: Victor Frye

From Dev to DevOps

Victor Frye — Wed, 22 Oct 2025 16:10:28 +0000

DevOps is more than a role; it's a culture and mindset that bridges the gap between development and operations. Any member of an IT organization or software company can embrace DevOps principles to improve collaboration, streamline processes, and enhance software delivery. Any person can carry more than one role. However, the literature for DevOps often starts with operations: system administrators, infrastructure engineers, and site reliability engineers (SREs). One of the best books on the topic, The Phoenix Project, is written from the perspective of an operations manager (and I highly recommend reading it). DevOps is about operations, but it is also about development. In truth, DevOps is about the entire software lifecycle and thus any person involved in it can learn and grow into a DevOps role. One such path is from developer to a DevOps engineer.

The common guidance

The most common guidance for learning DevOps is to start with tooling from the operations perspective with recommendations to start with Linux or containers or Kubernetes. Some may find success this way, but I find it misleading. DevOps is difficult to learn first and these technologies are complex. It also does not matter if your code is executed in a container, virtual machine, or bare-metal on a Windows server to practice DevOps. However, a well-informed DevOps engineer knows why containerization is used and why choice of operating system matters. Instead, I recommend starting with what you know and building on that. If you want to learn DevOps, start with the various roles that practice it: developers, testers, operations engineers, or project managers. Here, I am focused on the developer role because that is my background and what I know best.

The developer role

A developer is responsible for writing, testing, and maintaining code that forms the basis of software applications. They work with team members in various roles to:

Understand requirements of what to build and translate them into functional software.
Write clean, efficient, and quality code that is testable and maintainable.
Ensure the software is buildable, deployable, and operational in installed environments.
Deliver software that meets user needs and business goals in a timely manner.

One distinction is that a person may perform more than one role. For example, a developer may also be acting in the role of a manager, a designer, or a network engineer. The role of a developer is focused on developing software, but a person is often responsible for more than just writing code. Commonly, people in the developer role are also responsible for:

Troubleshooting business applications and triaging why behavior is not as expected.
Understanding legacy software and how it operates critical business logic.

In an enterprise and during a production incident, someone in the role of developer may be called to explain why insurance claims are still pending or an appointment booking failed. At the intersection of operations and development, a developer may be the first to know when a database failure or network outage is causing business disruption. In this way, developers are already acting outside of the limited scope of writing code. This is where DevOps comes in.

The DevOps shift

DevOps is about the entire software lifecycle and the interrelationships between traditional developer and operations roles. A person in the role of both developer and DevOps engineer is responsible for:

Understanding the entire software lifecycle, from planning feature requirements and writing code to deploying and maintaining applications in production.
Developing the solutions that support the software lifecycle, such as CI/CD pipelines, infrastructure in the form of code, and automating tests.
Knowing the difference between code written and value delivered.

Being a DevOps engineer may never include a direct title change. However, it may represent a growth in responsibilities commonly required for promotion. A developer who understands how to implement DevOps practices in tooling is one who can understand architecture, processes, and the business value of their application and how to drive change with teams. These are requirements that lead to senior and principal engineer roles.

Learning DevOps

Build systems

As a developer, you are already working with various technologies used for DevOps. The first is your build system. Today, software is built often. You need to build your application locally multiple times to test changes. You may use pipelines to build your application in another environment for verifying changes in a pull request. If you want to move from developer to DevOps engineer, the first place to start is understanding how your code is built and how it is run in all the different environments.

With .NET, this means understanding the differences between the .NET SDK and runtime and the dotnet CLI used to build, run, and publish code. For JavaScript, this means understanding the differences between development servers, bundling, and how static files are served in browsers. Every language has its own build tools and is different in execution environments. For .NET, the common language runtime (CLR) is used to run code on Windows, Linux, and macOS. For JavaScript, the runtime is the browser or Node.js. Understanding how your code is built and executed is critical to automation and maintenance. When you know this, you can begin to optimize and automate the process.

Source control concepts

Most developers are already using source control, such as Git, to store and collaborate on code. However, it is an underappreciated tool that is critical to developers and DevOps engineers alike. Source control systems are the foundation of collaboration and change management. GitOps is a practice that uses Git repositories as the source of truth for all kinds of code, including application code, infrastructure as code, configuration files, and CI/CD pipelines. Your branching strategies and pull request processes are key aspects of how you audit and manage change. Git is the tool, but GitOps is the adoption of DevOps practices for automation of operational concerns. Turns out this developer tool is also a DevOps tool.

Command-line and scripting

The command-line can be avoided by most developers these days. IDEs and graphical interfaces often abstract away the need to use a command-line interface (CLI). However, CLIs are necessary for DevOps automation. You can know F5 runs your code in the IDE, but when authoring a pipeline you need to know the commands that do this. Sometimes it becomes a series of commands, at which point you transition from simple commands to scripting. Commonly, the recommended scripting language is Bash as it is the native shell on Linux. However, any scripting language will help you as you learn DevOps. You can learn PowerShell or Python and still accomplish much of what you need to do. The key is to learn how to automate tasks that you would otherwise do manually without your mouse. Bash, PowerShell, and Python are all cross-platform choices. Practice navigating your file system, managing installed apps, and running your build commands from the command line.

Continuous integration and delivery

The best-known acronym in DevOps is CI/CD, which stands for continuous integration and continuous delivery (or deployment). As a developer, you may already be using CI/CD pipelines to build and test your code. It may be tied to your source control platform, such as GitHub Actions or Azure DevOps Pipelines, or GitLab CI/CD, or it may be a standalone system like Jenkins. This is likely the first tooling primarily associated with DevOps that you will start authoring as you learn the role of DevOps engineer. However, a pipeline in and of itself is not CI/CD. You can write a pipeline that copies source code to a server, but that does not give you continuous integration, delivery, or deployment. Continuous integration is improved through pipelines that compile code consistently, run tests to verify changes, or enforce quality through additional checks like linters and static code analyzers. Continuous delivery is about when your pipelines produce deployment-ready artifacts that are reusable and ready to deploy to any environment. Continuous deployment is achieved when your pipelines automatically deploy code to your environments without human intervention. A pipeline is a tool, but CI/CD is a practice and outcome. Learn pipeline tooling, but learn them with the goal of automating the steps needed for CI/CD.

Hosting and runtime environments

As you learn pipelines and the concepts of CI/CD, you will also need to understand where your code is run. This can vary widely depending on your organization or application. You may be running on bare-metal servers, virtual machines, containers, or serverless environments. You may be running on-premises or in the cloud. You may be using a platform-as-a-service (PaaS) or infrastructure-as-a-service (IaaS). The key is to understand where your code is run, the benefits and trade-offs of each environment, and how to get your code there. Learning Kubernetes in-depth may help if your organization is using it, but it is overkill for a static website or hobby project. It also doesn't help if your organization isn't using containers. Instead, focus on learning the environment your code is run in already. What operating system is used? What cloud provider? Is there differences between the platform used in development versus production?

Infrastructure as code

As you learn where your code is run, you will also need to learn how that environment is created and configured. This is where infrastructure as code (IaC) comes in and the developer skills you already possess can shine. IaC is the practice of defining your hosting and runtime environments through code. Various languages and tools exist for this, such as Terraform, Azure Bicep, Ansible, Pulumi, and PowerShell DSC. The value in IaC is the same as traditional source code: it is versioned, readable, and traceable. If you write something to create a virtual machine and never commit it to a central repository, it is lost. However, if you write a Terraform file to create a VM and commit it to source control, you can track changes, review history, and implement CI/CD practices to validate changes and achieve infrastructure automation. As a developer, you already know how to write code. You can learn IaC and apply your existing skills to an operations domain.

Continuous learning

The journey from developer to DevOps engineer is a surprisingly natural evolution. Developers already know their application and the value it delivers. They already know how to write code and collaborate with others. They already know the software lifecycle and the pains of delivering software. Learning DevOps is about expanding their existing knowledge and skills to automate and optimize the concerns outside of developing new features. The best way to learn DevOps is not necessarily learning Linux or Kubernetes, but instead mastering the tools they are already using and expanding knowledge of the whole system. Learn your how your code is built, where it is run, and how it gets there. Automate the friction in the process. When you start there, the mindset of DevOps fits into place:

When you understand your build system, you can optimize your code runtime and apply containerization efficiently.
When you know source control concepts, you can apply them to infrastructure and pipelines for version control, collaboration, and traceability.
When you possess command-line knowledge, you can automate tasks for test quality and CI/CD pipelines.
When you control your pipelines, you can automate for faster feedback and software delivery.
When you understand your hosting environment, you can optimize for scalability and apply effective deployment strategies.
When you write high quality code, you can apply the same principles to infrastructure, pipeline, and test code.

DevOps is not a set of tools or a team, but a fuzzier concept: a mindset and shared responsibility. The path to learning DevOps is likewise non-exact. The concepts and tooling mentioned are how I started to learn DevOps as a developer. Your path may be different, but the key is to start with what you know and use today. From there, you learn the adjacent concepts, the tooling, and the why behind it all. And then, you keep learning.

Aspire Roadmap 2025: Code-first DevOps, polyglot, and AI

Victor Frye — Fri, 01 Aug 2025 12:43:33 +0000

The Aspire team has recently published their 2025 roadmap, revealing an exciting evolution from local development orchestration to a comprehensive framework for DevOps concerns. Aspire launched with a code-first application model and instantaneous run experience, then expanded into deploy scenarios with publishers. This roadmap shows how it's becoming a complete code-first alternative to YAML-heavy DevOps toolchains while embracing polyglot development and AI workload orchestration.

While these are aspirational goals rather than firm commitments, they provide valuable insight into Aspire's direction. Let's explore the most compelling features and why they position Aspire as a game-changing DevOps framework for .NET, polyglot, and AI applications.

Code-first DevOps

DevOps combines development (Dev) and operations (Ops) to deliver software faster and with higher quality. While DevOps is fundamentally about people and processes, the technology and tooling often involve tedious YAML configuration files for CI/CD pipelines and infrastructure management. Aspire is changing this by providing a code-first approach to local development, testing, and deployment, replacing configuration complexity with familiar programming languages.

Local development

Aspire already excels at code-first application modeling in C#, expressing your entire architecture—databases, services, .NET projects, and polyglot components—then spinning it up locally with aspire run. No YAML configuration files, just standard .NET code that ideally mirrors your production architecture. The roadmap expands this with:

Improved container support: Shell commands, scripts, and interactive debugging inside containers
Multi-repo support: Native orchestration across multiple repositories
Built-in runtime acquisition: Automatic installation of Node.js, .NET, and other required runtimes

Aspire local development is a mature feature set already. These improvements focus on further simplifying the developer experience and tackling complex orchestration scenarios. Multi-repo support has been a long-standing pain point as many developers opt to separate components, like a frontend and backend, in separate repositories. Removing the monorepo requirement or custom cross-repo orchestration makes Aspire more accessible to many teams. You can already run polyglot applications in containers with Aspire, but continued improvements will allow more robust debugging and feedback loops with local containerized applications. The built-in runtime acquisition is both the most exciting and most daunting feature here. It may simplify the first run experience, which helps with onboarding and CI/CD pipelines and one area that I adore of Aspire. However, depending on its implementation, it could also lead to extra local machine complexity with Aspire managed runtimes versus system-wide runtimes. The local development experience is already fantastic and delivers the code-first developer experience Aspire promises. Therefore, I am optimistic that these improvements will build on that foundation.

Testing

Aspire's code-first model and instant run experience create ideal conditions for integration and end-to-end testing. You can spin up your entire application stack locally, creating an instant integration test environment with minimal friction. The Aspire.Hosting.Testing package provides this test host for xUnit and other testing frameworks and allows you to benefit from Aspire features like intelligent resource state notifications that eliminate arbitrary sleep times in tests. The roadmap adds advanced testing capabilities:

Partial app host execution: Run only specific components in tests to reduce overhead
Request redirection and mocking: Control traffic between components for chaos engineering
Code coverage support: Coverage collection and reporting for integration tests

Where local development is the mature foundation of Aspire, testing is currently a secondary benefit that often surprises users by revealing the true value of the framework. These improvements take the Aspire testing story to the next level. Aspire goes from being the startup tooling that manages your integration testing components to a chaos engineering and middleware validation powerhouse. The partial app host execution isn't limited to testing and reduces overhead in local development scenarios where certain components are not needed. In testing, this partial execution may allow each test to receive the benefit so API integrations can be isolated without starting up the frontend or further broken down to individual microservices that matter. Coupled together with request redirection and mocking of components, you could create test scenarios that simulate real-world failures between integrations and validate chaos behavior. Imagine chaos testing your application before you even deploy it from your machine with the same ease of unit testing. The code coverage support is the extra bonus reward: get code coverage metrics for your integration and chaos tests in a way that is often limited to unit tests? Yes, please! The roadmap suggests the current Aspire testing story is only in its infancy, and these improvements will make it a reason to adopt Aspire for testing alone if they materialize as envisioned.

Deployment

Deployment bridges development and customer value delivery. Aspire's local orchestration model naturally extends to cloud deployment scenarios. Aspire has been expanding to include deployment targets and publishers, simplifying the process of getting your application into production.
Currently, Aspire publishes artifacts like Bicep, Docker Compose, and Kubernetes manifests. You can deploy any Aspire resource the same way you would without Aspire, but with it you get seamless delivery to deployment targets like Azure Container Apps. While deployment targets are limited and opinionated, the roadmap addresses key enterprise needs that are still missing:

Additional deployment targets: Support for Azure App Service, Azure Functions, and improved Docker/Kubernetes workflows
Environment support: Define dev/stage/prod environments with specific configurations and secrets
CI/CD pipeline generation: Auto-generate GitHub Actions, Azure DevOps, and GitLab pipelines

Deployment is an emerging focus in the Aspire story. Azure Container Apps is the first focus for deployment target and flexible as a hosting platform, but it's not flexible enough for all enterprise scenarios even within corporate environments invested in Azure. The roadmap as expected promises more common Azure deployment targets for traditional .NET workloads like Azure App Service and Azure Functions, but it is still lacking in amazing polyglot deployment targets like Azure Static Web Apps. Environment support is critical for enterprise adoption as the majority of enterprises host multiple environments. DevOps practices may push us for consistency between environments, but there are always differences in configuration and secrets to isolate environments. The CI/CD pipeline generation in addition to environment support delivers on the idea of code-first DevOps: define your environments and application model in code, then generate the necessary pipelines to deploy it based on your code-first model. The overall deployment story is still evolving, but the question that will persist is whether Aspire can provide enough flexibility to meet the diverse needs of enterprises' existing applications. These features are a step in that direction. I hope the Aspire team delivers, and we see Aspire become a code-first framework for continuous delivery and deployment.

Polyglot aspirations

Aspire is not just a .NET framework; it is a polyglot orchestration framework that allows you to model and run conjoined applications in various languages. .NET, JavaScript, Python, and more are all supported, but the only first-class experience is in .NET projects. With the app host authored in C#, the service defaults project providing .NET best practices, and NuGet client integrations for simplifying configuration in your application code, Aspire is an amazing .NET developer experience. You can host JavaScript and Python applications, but you don't get the same level of integration and tooling. The roadmap reveals the Aspire team's ambition to provide a first-class polyglot experience that extends beyond .NET:

Uniform client integrations: Connection strings, configuration, and telemetry work consistently with new language support via npm (JavaScript) and pip (Python) packages
Templates and samples: Quickstarts and documentation for C#, JavaScript, and Python
Cross-language app host: Experimental WebAssembly support for multiple runtimes in a single process

The polyglot aspirations of Aspire are focusing on JavaScript and Python support first. The uniform client integrations with npm packages for JavaScript and other languages will get us closer to parity with the .NET experience. Improved documentation and more polyglot samples will also help as figuring out how to use Aspire currently relies on developers doing the translation between C# and other languages themselves. Technically a hosting integration, but if Aspire supports the Aspire.Hosting.Testing package in JavaScript I would be ecstatic. Documentation and packages together could elevate the polyglot experience to make Aspire stand out beyond traditional .NET developers. It may invite more developers to experiment with the .NET platform beyond Aspire as well.

The cross-language app host is a fascinating item and the one I find hardest to envision myself. Will this be a way to write the app host without .NET? Will it wrap all the runtimes in a single process on your computer? What will it actually look like? The roadmap tells us it is experimental, so it may never materialize, or it may be something we start to see soon. I will be watching this closely as it starts to take shape and the value becomes clearer.

Artificial intelligence

While AI dominates software conversations, Aspire has focused on fundamental developer experience improvements rather than AI-first features. As AI applications continue to be mainstream, Aspire is positioned to apply its orchestration strengths to AI workloads. The roadmap outlines several AI-specific features:

Token usage visualization: Real-time token counts, latency, and evaluation metadata in the dashboard
LLM-specific metrics: Native support for generative AI telemetry, including model name, temperature, and function call traces
Azure AI Foundry: Integration for building agent-based applications
Aspire MCP server: Optional runtime endpoint exposing the Aspire model as an MCP server for AI agents

Building AI applications is itself a nascent discipline. The Aspire team appears to be taking a measured approach to AI integration instead of branding itself another set of AI-native tools. These Aspire AI features are focused on two key areas: observability and agents. Observability is another area Aspire already excels at with the Aspire dashboard. Token usage and LLM-specific metrics visualizations in the Aspire dashboard will be a wonderful addition to the existing telemetry and observability features. It stays true to the natural value of Aspire while also extending to needs of AI local development needs.

In agentic regards, Aspire works but has a lot of limitations. Existing AI integrations, like Azure OpenAI and Ollama, provide some options for local and cloud-hosted LLMs. The integration with Azure AI Foundry may extend the catalog and options for LLMs. It will be exceptionally interesting if the integration supports Azure AI Foundry Local capabilities to provide a unified catalog of models both locally and in the cloud. The Aspire MCP server likewise adds agentic capabilities to Aspire. Model Context Protocol (MCP) is becoming an industry standard for AI agents communicating, understanding, and interacting with outside systems. An Aspire MCP server could provide development tools like GitHub Copilot with deep context on your application model and all the resources Aspire manages. I am all for more intelligent development workflows. Like so many other technologies, Aspire is targeting AI trends and trying to provide its own value in the space.

Aspire tooling

As Aspire evolves into a mature framework, its tooling ecosystem continues expanding beyond the core .NET SDK. The roadmap includes several improvements:

Aspire CLI: Continued improvements and unified commands
WinGet and Homebrew installers: Standard install support for Windows and macOS
VS Code extension: Run, debug, and orchestrate polyglot Aspire applications in VS Code

The tooling of Aspire is a meta story and so are its roadmap items. The code-first DevOps value and the polyglot aspirations, they all deliver on a core premise of Aspire: a simplified developer experience. When the tooling to setup Aspire or interact with it isn't easy, the core premise is lost. The Aspire CLI has already started this meta story with my favorite command, aspire run, which provides a consistent way to run your Aspire hosted applications locally. Continued improvements to the CLI and other commands will help make it easier to adopt and utilize Aspire. The WinGet and Homebrew installers are similar in value and may simplify installing the Aspire CLI which is already more complex than it should be. Finally, the VS Code extension may help deliver on the polyglot aspirations of Aspire by making development with Aspire more accessible to the tools JavaScript and Python developers already use without relying on CLI knowledge. Sure, CLI commands mean you can do it today but installing the Aspire CLI and generating projects requires a guide of the right CLI commands. Overall, the meta story of these tools is to simplify using Aspire so that Aspire can simplify your developer experience.

Final thoughts

The 2025 roadmap that the Aspire team published is an exciting glimpse into a rapidly evolving framework. Nothing is a commitment, but the vision tells a story of what Aspire is developing into: a code-first DevOps framework that simplifies local development, testing, and deployment while embracing polyglot development and AI orchestration. I am incredibly excited by this roadmap as it aligns with my own dreams for Aspire. I love what it is today and recommend it to every .NET developer and some polyglot developers. If the Aspire team can deliver on half of these features, it will only continue to be a game-changer for developing distributed applications.

Let me know what you think of Aspire and where it is going. Are you excited about the roadmap? Do you think Aspire can deliver on these promises? I would love to hear your thoughts and experiences with Aspire so far.

Reviewing Aspire.JS: Current state of Aspire for JavaScript

Victor Frye — Fri, 01 Aug 2025 12:42:00 +0000

Aspire is the coolest thing in software development right now. That's a statement I frequently make, but it comes from a place of genuine excitement for this nascent framework that is transforming how we can model, run, and deploy applications. Local development with Aspire is effortless regardless of the complexity of your architecture. Aspire is a part of the .NET platform, but it extends past .NET to provide polyglot orchestration for JavaScript, Python, and other languages.

One reason I refer to Aspire as the coolest thing in software development is my frequent use of it in JavaScript projects. Whether it's a simple static site or a full-stack application, Aspire has become my go-to tool for local development.

This post is a review of Aspire for JavaScript including current state, my personal experiences, and future aspirations. If you are a JavaScript, .NET, or polyglot developer interested in Aspire, this analysis is for you. If you are not familiar with Aspire, you may want to read a breakdown of its key features first.

Current state

Aspire in its current state is a code-first orchestration framework written in C# but enabling local development and hosting of polyglot applications. JavaScript and .NET exist in harmony with Aspire. Given the common stack of a JavaScript web frontend, a .NET web API backend, and a containerized database or other backing services, Aspire hosts the entire stack and abstracts away the different mechanisms for running and connecting each component.

The above stack is the apparent assumption of Aspire for JavaScript. Aspire allows for modeling and running JavaScript backends, full-stack JavaScript applications, and scripts, but given the .NET-first nature of Aspire, you will be writing some C# code if you use Aspire. Accepting this for the app host, the orchestrator and C# model, Aspire provides two extension points of note for JavaScript development: Integration packages and deployment targets.

Integrations packages

Integration packages are the libraries that extend Aspire to support the various projects, executables, containers, and services that make up your application. These packages are hosted as NuGet packages and can either be hosting or client integrations. Hosting integrations extend the app host of Aspire to model and run components like a JavaScript web app. Client integrations are libraries that allow you to consume the Aspire configurations and defaults to connect to the hosted components. However, client integrations are exclusive to .NET projects given they are packed as NuGet packages.

This still leaves a variety of hosting integrations for JavaScript development to benefit from. The following are some of the most relevant:

Aspire.Hosting.NodeJs: Provides hosting for Node.js applications via node or npm scripts
CommunityToolkit.Aspire.Hosting.Bun: Provides hosting for Bun applications
CommunityToolkit.Aspire.Hosting.Deno: Provides hosting for Deno applications
Aspire.Hosting.PostgreSQL: Provides hosting for PostgreSQL database via Docker Hub registry postgres images
Aspire.Hosting.MongoDB: Provides hosting for MongoDB database via Docker Hub registry mongo images
Aspire.Hosting.Redis: Provides hosting for Redis via Docker Hub registry redis images
Aspire.Hosting.Azure.Storage: Provides hosting for Microsoft Azure cloud storage services, including Blob, Queue, Table, and Azurite emulation
Aspire.Hosting.Testing: Provides a test host for .NET unit testing frameworks

Overall, the packages provide flexibility of hosting JavaScript apps with the Node.js, Bun, or Deno runtimes. Databases and cloud service hosting include popular JavaScript data solutions like PostgreSQL, MongoDB, Redis, and Azure Blob Storage. Together, Aspire still provides the same local development experience for JavaScript application as it does for .NET with instantaneous runs and abstractions over other configuration files. The major deficits are you must minimally write C# code for the Aspire app host and to consume the Aspire host for testing, you will need to write integration tests using .NET testing frameworks like xUnit. For true polyglot developers familiar with both JavaScript and .NET, this is a non-issue that provides all the benefits of Aspire with the flexibility of using JavaScript for what JavaScript is best at. However, for a JavaScript only developer, there are extra barriers to entry here that Aspire has yet to solve.

Deployment targets

Deployment is an emerging focus in the Aspire story. Applications orchestrated with Aspire can be deployed anywhere the same way you would deploy without Aspire, however the focus here is deployment through Aspire. Aspire is expanding to include publishers and deployment targets, taking your modeled application and using it to generate artifacts like Bicep and container images. Given Aspire's origins in .NET and Microsoft solutions, the initial deployment targets are opinionated and limited. By default, the easiest deployment target is Azure Container Apps, a serverless platform for running containerized applications. However, there is a fundamental flaw here for JavaScript developers: hosting with Azure Containers Apps assumes you need a server.

JavaScript developers are accustomed to a true serverless experience, one in which the web browser is the host environment. Frameworks like Next.js allow for server-side computation, but many JavaScript frameworks and applications are designed to run entirely in the browser using a bundle of JavaScript, HTML, and CSS. This has a lot of benefits for developers, including:

No server management: No need to manage servers or containers, just a static file host
Instant scaling: Static files can be served from a CDN, scaling automatically with demand
Lower costs: Static file hosting is often cheaper than running containers or VMs

And so much more. This is antithetical to traditional .NET development and represents a fundamental difference in JavaScript versus .NET. Some JavaScript developers may opt for containerized hosting due to enterprise infrastructure or for self-managed static web servers like Nginx, but Azure already provides a first-class static web hosting solution with Azure Static Web Apps. Azure Static Web Apps are nowhere to be found in the Aspire deployment story, which is a major gap for Aspire for JavaScript.

My Aspire.JS story

To understand how Aspire fits JavaScript development currently and potentially in the future, it is helpful to understand how a developer who has adopted Aspire already uses it. I am a full-stack developer who currently favors .NET for backend development, React for frontend development, and Azure for cloud hosting. I started using Aspire for a sample .NET web API that I wanted to run on macOS and Windows, so that anyone could pull down the code and run it with minimal configuration. Aspire was perfect for this, so I started using it for all my .NET projects. This in turn led me to use Aspire to host a React frontend alongside my web API and database, which also proved to be effortless. Finally, I asked the question: Why not use Aspire for my JavaScript only projects?

I have 3 static sites that I maintain, including my personal blog, and I wanted to use Aspire for local development to provide a consistent local development experience across all my projects. It works. Every personal project, including live websites or demo applications, is locally orchestrated with Aspire by default. I also recommend it for any enterprise .NET project I work on. However, the barrier of recommendation stops at projects that do not include .NET components currently. Aspire is currently an excellent choice for .NET and polyglot projects that include .NET, but the benefits of Aspire for JavaScript only or polyglot projects without .NET are not an easy sell. The C# app host, NuGet client integrations, and lack of polyglot deployment targets that do not align are all barriers to entry for JavaScript developers.

The C# app host is a non-issue for me as a .NET developer, but for any project not already using .NET, it means extra SDKs to install and a new language to learn. Admittedly, the app host is not complex C# code until you start creating your own custom components. It is the download of the .NET SDK that is the high barrier. The NuGet client integrations are less a barrier and more a missing feature to sell the value story. Finally, deployment targets are a nascent feature in a nascent framework. I started using Aspire without its deployment features due to feature immaturity. To this day, I favor Azure Container Apps or Azure Functions for .NET workloads and Azure Static Web Apps for JavaScript workloads and handle deployment separately from Aspire. Together, this means the Aspire story for non-.NET applications adds .NET as a development dependency and is missing client integrations and deployment flexibility I would expect for recommendation.

Future aspirations

Aspire recently published their 2025 roadmap, which includes several features that may solve the current limitations of Aspire for JavaScript. The most exciting are:

Polyglot client integrations: Connection strings, configuration, and telemetry work consistently via npm packages as they do with existing NuGet packages for .NET projects
Templates and samples: More documentation and quickstart examples for JavaScript
Cross-language app host: An experimental WebAssembly app host that may reduce .NET friction for JavaScript developers authoring the Aspire app host

These features may further make Aspire an accessible choice for JavaScript developers and provide some of the .NET exclusive benefits for JavaScript components in your applications. The npm client integration packages excite me the most as a polyglot developer because it would allow me to integrate databases and cloud services like Azure Storage into my JavaScript components with the same reduced configuration as Aspire is doing for .NET projects. This adds parity in developer experience and closes the gap for recommendation and adoption of Aspire for JavaScript development. Documentation improvements are also always welcome and ease adoption. The cross-language app host is interesting, but I am still unsure of what it may amount to or if it'll even materialize. If it does, maybe it removes the .NET SDK download as a barrier. These features are directional and not commitments but provide a hope for increased parity with Aspire .NET developer experience.

The remaining gap is deployment. This is an emerging area and the .NET story itself is still evolving for deploying with Aspire. However, I am actively watching for how this matures and the targets that get first-class support. If static hosting targets like Azure Static Web Apps are added, Aspire for JavaScript becomes a much more compelling recommendation. If Aspire only provides first-class support for traditionally .NET hosting targets like Azure App Service, Azure Functions, and Azure Container Apps, then the polyglot story remains incomplete.

Final assessment

Aspire is the coolest thing in software development right now and is actively evolving. For polyglot developers familiar with .NET, Aspire is a game-changer and you should experiment with adding it yourself. However, for JavaScript development and polyglot applications without .NET, there are still barriers to entry that prevent Aspire from being a compelling recommendation. Can you do it? Absolutely. Do I use Aspire for JavaScript development? Yes. Do I recommend it for JavaScript only projects? Not yet. But maybe in the future. Maybe soon.

dotnet run file.cs: The new file-based application model

Victor Frye — Wed, 02 Jul 2025 13:00:00 +0000

I missed something at Microsoft Build 2025: the announcement of the new dotnet run file.cs model in .NET 10 Preview 4. This is a new paradigm for running and writing .NET applications and if you are reading this, you might not be the target of this feature. However, you will probably meet or read C# code that is written this way.

This article will explore the new feature of dotnet run file.cs and the value it brings to the .NET ecosystem. Run it!

The Current Project-Based Model

Today, if I wanted to write a simple C# console application that output "Hello, World!", I need to do the following:

Install the .NET SDK.
Install an IDE or text editor like Visual Studio or Visual Studio Code.
Create a new .NET project using the IDE or the dotnet new CLI command.
Write my code in the Program.cs file.

None of this is changing, or at least the steps. However, the output of this today is as given the command: dotnet new console --name HelloWorld:

File actions would have been taken:
  Create: ./HelloWorld.csproj
  Create: ./Program.cs

Processing post-creation actions...
Action would have been taken automatically:
   Restore NuGet packages required by this project

The above is the dry run output of the dotnet new command. Notice two files are created: HelloWorld.csproj and Program.cs. The csproj file is an XML file that contains information any .NET developer is all too familiar with. The Program.cs file is where I write my code. Additionally, you will quickly see obj and bin directories created and start populating as you write and publish your application. Do you know what both directories are for, even today? Do you find XML friendly to read? Microsoft asked a new question: Is this all overwhelming for someone new?

The keyword above was new. I invite you to recall your days learning to code and suppress your experienced instincts. When I do, I remember sitting in a classroom feeling like I might never understand programming and would fail. C# was my first language. We have bootcamps, universities, and online courses in excess to help new developers. That is working, but they are learning JavaScript or Python. Why? Because the onboarding experience is easier. The barrier to entry lower.

What if this changed? Introducing the new dotnet run file.cs paradigm.

The New File-Based Model

The dotnet run we keep discussing is the Dotnet CLI command any .NET command-line user is familiar with. However, the file.cs is in reference to a new single file-based application model. That means in our steps from earlier, we change them to the following:

Install the .NET SDK.
Install an IDE or text editor like Visual Studio Code.
Create a new C# file, e.g. hello.cs.
Write my code in the hello.cs file.

The steps are incredibly similar but also simplified. You need the .NET SDK and a tool for writing code still, but you no longer need to understand a complex project generation process and only have one file to manage. Let's review it:

#!/usr/bin/dotnet run
#:sdk Microsoft.NET.Sdk.Web
#:property AssemblyName VictorFrye.HelloWorld

var app = WebApplication.CreateBuilder(args).Build();

app.UseHttpsRedirection();

app.MapGet("/hello", () => "Hello World!");

await app.RunAsync();

That is it. I could link to a repository, but if you copy and paste this you get a complete .NET application you can run. There is no csproj file, and obj and bin directories are not created in your working directory. And if you run the command dotnet run hello.cs, you get an active Kestrel web server that responds with "Hello World!". The latter half of the code is top-level statements, a feature not so new. However, the first three lines are special.

The first line is a shebang: a Unix convention that tells the system how to execute the file. In this case, it tells the system to use the dotnet run command to execute the file. With this new paradigm, you must have the .NET SDK installed and Dotnet CLI available still. A shebang is not required, but it does enable running the file without explicitly calling dotnet run on Unix-like systems. This is cool, but mostly just a convenience.

The second and third lines are new directives. You may be using directives in your code today, such as #if DEBUG or #region Feature X. However, the new #: directives are unique to the run file paradigm. The .csproj file normally tells our .NET application critical information like SDKs, MSBuild properties, or NuGet packages to use. The run file paradigm still supports these, but instead you use a #:sdk directive or #:property directive. In this case, I'm using the Microsoft.NET.Sdk.Web SDK to pull in ASP.NET Core features for web APIs and setting the assembly name to VictorFrye.HelloWorld because I like my name. These new directives are only for the run file paradigm, and you will get warnings if you try to use them in a traditional project model.

Behind the scenes, everything is still there. The project file still exists but is virtual and interpreted by the Dotnet CLI. The obj and bin directories are created, but in a temporary location that is abstracted away. The application is still built and run like any other .NET application. The difference is in the simplicity of authoring C#. However, when the project reaches maturity or someone is ready to take it to the next level, they can convert the file-based application to a traditional project-based application. All you must do is run the following:

dotnet project convert hello.cs

The Value Added

I am really excited about the dotnet run file.cs. The primary users targeted are new developers. This is a win if Microsoft succeeds and more developers embrace modern .NET applications. Some might be concerned about not learning all the details of the full project-based application model, but new developers learning .NET mean a larger .NET community, new libraries, and more innovation in the ecosystem. This is a huge win for the .NET developer community.

However, the value added doesn't stop there. File-based applications are also great for scripts and small utility apps. You don't need a folder structure or a csproj file. You can now write a couple C# scripts to help you maintain your existing codebase or automate tasks. This is a huge win for scripting capabilities and reducing project overhead.

Another use-case is one you might have to read yourself: .NET samples. Sample applications are used by libraries to showcase how to use specific features or APIs. They are also used by conference speakers and at meetups to illustrate concepts or provide live demos of features. In this article itself, I would normally have to create a full project to demonstrate the feature, and I would link the repository so a reader could copy it exactly and reference it or run it themselves. Now, I can provide the entire sample in a code block that is easy to copy and paste. This is a huge win for documentation and sample authors.

The Limitations So Far

Right now, file-based applications are limited to a single file. They are also unsupported in Visual Studio, favoring Visual Studio Code as a more likely editor for targeted users. Finally, it is only in .NET 10 Preview versions at the moment. It will not be until November 2025 that we see the first general availability release of file-based applications and likely time after before we see new developers learning in this form or a C# scripting revolution.

Concluding Remarks

The dotnet run file.cs paradigm is a new way to write and run .NET applications. It may or may not be for you, but the goal is a more inclusive and accessible .NET ecosystem. The best outcome is more developers learning and using .NET. Maybe C# scripts take off and we see C# become the new Python. Maybe documentation and sample applications get less verbose. The future is hard to predict, but I am hopeful for a future where I see file-based C# applications in the wild.

Local Friendly .NET Aspire: Modeling your local environment

Victor Frye — Mon, 30 Jun 2025 13:00:00 +0000

.NET Aspire is a new framework for building cloud-native and distributed applications. It brings a host of key features as I've previously discussed, but my two favorites are the ability to model your application stack in C# code and the instant local development environment you get after doing so.

In this post, I'll explore these features through two sample applications: a classic CRUD application with containerized backing services and an AI prototype that relies on cloud services. Both showcase how Aspire solves the complexity of running distributed applications locally. You can find the code for these examples on GitHub at victorfrye/crudcounter and victorfrye/mockingmirror.

Modeling your application

To start modeling our application, we need an Aspire app host project. This is a .NET project that uses the Aspire SDK to define the resources and integrations needed for our application. I cover how to add an Aspire app host project in my command line guide.

Here I'll show you two app host projects. Two files make up the core of the Aspire app host: a Program.cs file and a .csproj file. These can be extended to your pleasure, but these two files are the current minimum. The csproj file will provide our SDK and hosting integration package references, while the Program.cs will be the C# code for modeling and serve as the entrypoint for our local application going forward.

CRUD application

First, the csproj file for our CRUD application host looks like this:

<Project Sdk="Microsoft.NET.Sdk">

  <Sdk Name="Aspire.AppHost.Sdk" Version="9.3.0" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>

    <AssemblyName>VictorFrye.CrudCounter.AppHost</AssemblyName>
    <RootNamespace>VictorFrye.CrudCounter.AppHost</RootNamespace>

    <UserSecretsId>2bad5002-9943-41cd-9a77-ec579ba4a680</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.3.0" />
    <PackageReference Include="Aspire.Hosting.NodeJs" Version="9.3.0" />
    <PackageReference Include="Aspire.Hosting.Redis" Version="9.3.0" />
    <PackageReference Include="Aspire.Hosting.SqlServer" Version="9.3.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\WebApi\WebApi.csproj" />
  </ItemGroup>

  <Target Name="RestoreNpm" BeforeTargets="Build" Condition=" '$(DesignTimeBuild)' != 'true' ">
    <ItemGroup>
      <PackageJsons Include="..\WebClient\package.json" />
    </ItemGroup>

    <!-- Install npm packages if node_modules is missing -->
    <Message Importance="Normal" Text="Installing npm packages for %(PackageJsons.RelativeDir)"
      Condition="!Exists('%(PackageJsons.RootDir)%(PackageJsons.Directory)/node_modules')" />
    <Exec Command="npm install" WorkingDirectory="%(PackageJsons.RootDir)%(PackageJsons.Directory)"
      Condition="!Exists('%(PackageJsons.RootDir)%(PackageJsons.Directory)/node_modules')" />
  </Target>

</Project>

There are four callouts here:

The Sdk element specifies we are using the Aspire SDK for this project. This extends our .NET SDK for Aspire app hosting capabilities.
The ProjectReference element includes a reference to my existing ASP.NET Core Web API project. Aspire integrates seamlessly with other .NET projects.
The PackageReference item group includes a mix of dependencies for hosting our various services, e.g. Node.js for the web client, Redis for caching, and SQL Server for our database.
The RestoreNpm target, a nasty bit of build magic that I'm using to ensure all npm packages are installed for the web client for first-time repository runs.

You could get away with only the Sdk element, but why reinvent the wheel? Referencing existing .NET projects is commonplace in the ecosystem already. You could build your own resource models, but prebuilt packages from Microsoft are less work and at this stage we probably don't even know how. Finally, that RestoreNpm target is a huge convenience for our end-goal: a single step to run our entire application.

Okay, but what about the actual C# code? Let's look at the Program.cs file now:

var builder = DistributedApplication.CreateBuilder(args);

var sql = builder.AddSqlServer("sql")
                 .AddDatabase("db");

var cache = builder.AddRedis("cache");

var api = builder.AddProject<Projects.WebApi>("api")
                 .WithReference(sql)
                 .WaitFor(sql)
                 .WithReference(cache)
                 .WaitFor(cache)
                 .WithHttpHealthCheck("/alive")
                 .WithExternalHttpEndpoints();

builder.AddNpmApp("client", "../WebClient", "dev")
       .WithReference(api)
       .WaitFor(api)
       .WithEnvironment("NEXT_PUBLIC_API_BASEURL", api.GetEndpoint("https"))
       .WithHttpEndpoint(env: "PORT");

await builder.Build().RunAsync();

This code models our entire application stack in a few lines:

Creates backing infrastructure, i.e. SQL Server and Redis cache as containers
References our .NET web API project and configures it to wait for dependencies
Adds our JavaScript frontend and connects it to the API
Orchestrates everything to run together

Without Aspire, this would require multiple manual steps: starting containers, launching the API, configuring the frontend with the right API URL, and hoping everything connects correctly.

With Aspire, we do it in a single step in three forms: press F5 in your IDE, run dotnet run --project "Path/To/MyAspireApp.AppHost" in your terminal, or aspire run with the Aspire CLI.

If you chose to install the Aspire CLI and run that way, you are greeted with a beautiful output like this:

Dashboard:
📈  https://localhost:17280/login?t=af9ee87cf516605f0639052a6731c2d0

╭──────────┬───────────────────────────┬─────────┬────────────────────────╮ 
│ Resource │ Type                      │ State   │ Endpoint(s)            │ 
├──────────┼───────────────────────────┼─────────┼────────────────────────┤ 
│ api      │ Project                   │ Running │ https://localhost:7558 │ 
│          │                           │         │ http://localhost:5556  │ 
│ cache    │ Container                 │ Running │ tcp://localhost:60771  │ 
│ client   │ Executable                │ Running │ http://localhost:60772 │ 
│ db       │ SqlServerDatabaseResource │ Running │ None                   │ 
│ sql      │ Container                 │ Running │ tcp://localhost:60773  │ 
╰──────────┴───────────────────────────┴─────────┴────────────────────────╯ 
Press CTRL-C to stop the app host and exit.

Regardless of using the Aspire CLI or not, you will see a dashboard in your terminal or pop out in your browser. This is the Aspire dashboard, which provides a web portal to your local environment with a resource table or graph, console logs for each, traces for requests between resources, and stateful information about each resource.

Okay, but what if not everything is local? Well let's look at the AI sample now.

AI application

First, the csproj file for our AI application host looks like this:

<Project Sdk="Microsoft.NET.Sdk">

  <Sdk Name="Aspire.AppHost.Sdk" Version="9.3.0" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>

    <AssemblyName>VictorFrye.MockingMirror.AppHost</AssemblyName>
    <RootNamespace>VictorFrye.MockingMirror.AppHost</RootNamespace>

   <UserSecretsId>353d8321-8cea-41fd-b09b-0503c184b4c8</UserSecretsId>  
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.3.0" />
    <PackageReference Include="Aspire.Hosting.Azure.CognitiveServices" Version="9.3.0" />
    <PackageReference Include="Aspire.Hosting.NodeJs" Version="9.3.0" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\WebApi\WebApi.csproj" />
  </ItemGroup>

  <Target Name="RestoreNpm" BeforeTargets="Build" Condition=" '$(DesignTimeBuild)' != 'true' ">
    <ItemGroup>
      <PackageJsons Include="..\WebClient\package.json" />
    </ItemGroup>

    <!-- Install npm packages if node_modules is missing -->
    <Message Importance="Normal" Text="Installing npm packages for %(PackageJsons.RelativeDir)"
      Condition="!Exists('%(PackageJsons.RootDir)%(PackageJsons.Directory)/node_modules')" />
    <Exec Command="npm install" WorkingDirectory="%(PackageJsons.RootDir)%(PackageJsons.Directory)"
      Condition="!Exists('%(PackageJsons.RootDir)%(PackageJsons.Directory)/node_modules')" />
  </Target>

</Project>

Very similar to the CRUD app with the SDK, package references, project references, and a custom target. The main difference is the Aspire.Hosting.Azure.CognitiveServices package reference, which provides the Azure AI services we will be using. And the Program.cs? This gets a bit different:

var builder = DistributedApplication.CreateBuilder(args);

var oaiName = builder.AddParameter("OpenAIName");
var oaiResourceGroup = builder.AddParameter("OpenAIResourceGroup");
var oaiModel = builder.AddParameter("OpenAIModel");
var speechKey = builder.AddParameter("SpeechKey", secret: true);
var speechRegion = builder.AddParameter("SpeechRegion");

var openai = builder.AddAzureOpenAI("openai")
                    .AsExisting(oaiName, oaiResourceGroup);

var api = builder.AddProject<Projects.WebApi>("api")
                 .WithReference(openai)
                 .WaitFor(openai)
                 .WithEnvironment("ChatClientSettings__DeploymentName", oaiModel)
                 .WithEnvironment("SpeechClientSettings__ApiKey", speechKey)
                 .WithEnvironment("SpeechClientSettings__Region", speechRegion)
                 .WithHttpHealthCheck("/alive")
                 .WithExternalHttpEndpoints();

builder.AddNpmApp("client", "../WebClient", "dev")
       .WithReference(api)
       .WaitFor(api)
       .WithEnvironment("NEXT_PUBLIC_API_BASEURL", api.GetEndpoint("https"))
       .WithHttpEndpoint(env: "PORT")
       .WithExternalHttpEndpoints();

await builder.Build().RunAsync();

In this example, we model external cloud services that can't run locally. We use parameters to extract variables, such as API keys and Azure resource information, from local configuration stores. We use the AsExisting to reference pre-provisioned Azure OpenAI resources with an existing Aspire hosting integration. For Azure AI Speech which does not have an Aspire integration, we simply pass the parameter values as environment variables. This approach connects our web API to backing Azure AI services while still allowing us the convenience of Aspire local orchestration.

There's a lot to consume here, but the key takeaway is you have options. Regardless of whether your local environment is fully isolated or has external dependencies, regardless of if your external dependencies have packages for them already or not, you can start to model out your application with Aspire and we get the same benefits as that CRUD application: we can start up what is needed locally with a single step. Again, I pick aspire run:

Dashboard:
📈  https://localhost:17244/login?t=e5f80d45a566a13a40755d0154e1d410

╭─────────────────────┬───────────────────────────┬─────────┬────────────────────────╮                
│ Resource            │ Type                      │ State   │ Endpoint(s)            │                
├─────────────────────┼───────────────────────────┼─────────┼────────────────────────┤                
│ api                 │ Project                   │ Running │ https://localhost:7034 │                
│                     │                           │         │ http://localhost:5170  │                
│ client              │ Executable                │ Running │ http://localhost:63526 │                
│ openai              │ AzureOpenAIResource       │ Running │ None                   │                
│ openai-roles        │ AzureProvisioningResource │ Running │ None                   │                
│ OpenAIModel         │ Parameter                 │ Unknown │ None                   │                
│ OpenAIName          │ Parameter                 │ Unknown │ None                   │                
│ OpenAIResourceGroup │ Parameter                 │ Unknown │ None                   │                
│ SpeechKey           │ Parameter                 │ Unknown │ None                   │                
│ SpeechRegion        │ Parameter                 │ Unknown │ None                   │                
╰─────────────────────┴───────────────────────────┴─────────┴────────────────────────╯                
Press CTRL-C to stop the app host and exit.

Our dashboard still gives us a portal to interact with our local environment and states of resources. I get extra information for the Azure OpenAI service as I was able to use an existing hosting integration, despite re-using an existing service. For the Speech service, I don't have to configure anything extra for other projects and can just target the configuration for the AppHost project. My backend and frontend still benefit entirely from the Aspire dashboard and my application is up and running with the press of a button.

The Aspire parameters and Azure configuration use the options pattern to bind values from configuration sources. The parameters use the Parameters section of your configuration sources, such as app settings, user secrets, or environment variables, while the Azure configuration uses the Azure section. For more on these specifically, you can refer to the Aspire documentation on external parameters and Azure local provisioning.

So now we have two different kinds of applications modeled in Aspire, one fully local and one with external dependencies. Both of these applications can be run with a single command, aspire run, and provide a dashboard to interact with them. Cool, right?

Why this matters?

This modeling approach aligns perfectly with how we think about our applications, both locally and in deployment. The Aspire app host serves as a bill of materials for our application, defining all integrations and parameters needed to run.

The immediate benefit is a dramatically improved developer experience. New team members can clone the repository, run a single command (aspire run), and have a functional environment without learning setup procedures for each component. When you add new services to your stack, just update the model.

This pre-modeled environment also serves as an integration testing foundation. The Aspire.Hosting.Testing package lets you run your application host in test frameworks like xUnit or MSTest, enabling tests that validate your entire stack or specific components.

Beyond the inner loop, Aspire is addressing deployment scenarios by generating infrastructure as code for Bicep, Terraform, Kubernetes, and more based on your application model with publishers.

Final thoughts

The service defaults were what drew me to Aspire initially, but my interest quickly evolved into excitement about the transformative developer experience it offers. The simplicity of modeling your application and running it locally with a single command changes expectations for development inner loop.

All of my projects, including pure JavaScript apps like this blog, now run with Aspire because it's become my new standard. I encourage you to try it in your projects and experience how it reshapes your workflow. This feels like the future of .NET development, and I'll continue exploring Aspire's capabilities in future posts.

Adding .NET Aspire: A command line user's guide

Victor Frye — Fri, 27 Jun 2025 13:00:00 +0000

.NET Aspire is a new framework for building cloud-native distributed applications that simplifies local development and deployment. Aspire offers significant benefits through its application modeling and orchestration capabilities. But how do you actually add Aspire to your projects?

In this guide, I'll walk through command line options to adding Aspire into both new and existing applications. Whether you're starting from scratch or enhancing an established project, the dotnet CLI provides templates to generate projects, new solutions, or common standalone files. This post focuses on the Aspire project templates and another useful tool, the aspire CLI, using command lines for those interested in checking out .NET Aspire.

Let's dive into adding Aspire to your .NET projects through the command line!

Adding Aspire to your project

You can do all of this in Visual Studio or the dotnet CLI, but I will be guiding with CLI commands as they are universal across all OSes and IDEs. Also, CLI is just more fun, right?

With Aspire, you will have two new projects in your solution: AppHost and ServiceDefaults. These can have any name, but these names are the standard. The AppHost project is your local environment entrypoint and where you will model your application. The ServiceDefaults sets up default configurations deemed best practice for distributed applications. To add these, you can use the Aspire project templates. Using the dotnet CLI, you can run the following command options:

Install Aspire templates

First thing you'll have to do is install the Aspire project templates. This will provide the necessary scaffolding for any of the other commands below to work. You can do this by running the following command in your terminal:

dotnet new install Aspire.ProjectTemplates

You may have to append a @X.X.X version and/or the --force option to install a newer version of the templates.

Option 1: Add AppHost and ServiceDefaults

To add both the AppHost and ServiceDefaults projects to your existing solution, you can run the following command:

dotnet new aspire --name "MyAspireApp" --output .

This provides a both new projects. The --name option specifies the root solution name and both projects will be created as MyAspireApp.AppHost and MyAspireApp.ServiceDefaults in this example. The --output option specifies the current directory as the output location, but you can change this to any directory you prefer such as src.

Option 2: Add AppHost only

If you only want to start with the AppHost project, you can run the following template option:

dotnet new aspire-apphost --name "MyAspireApp.AppHost" --output "AppHost"

This will create only the AppHost project. This provides the local orchestration and entrypoint for Aspire applications. For the above, the --name option now specifies the fully qualified project name, MyAspireApp.AppHost, and the --output option specifies a new directory called AppHost to contain these specific project files.

Option 3: Add ServiceDefaults only

If you want to start with just the ServiceDefaults project, you can run the following command:

dotnet new aspire-servicedefaults --name "MyAspireApp.ServiceDefaults" --output "ServiceDefaults"

This will create only the ServiceDefaults project. This project is a shared .NET library that contains useful defaults for distributed applications, such as HTTP resiliency and health check configuration. The --name option specifies the fully qualified project name, MyAspireApp.ServiceDefaults, and the --output option specifies a new directory called ServiceDefaults to contain these specific project files.

Option 4: Start a new solution with Aspire

One final option is the Aspire starter template. This will create a new solution with both the AppHost and ServiceDefaults projects, plus a Blazor web frontend and web API backend service. You can run the following command to create a new solution with all of these projects:

dotnet new aspire-starter --name "MyAspireApp" --output .

The resulting solution will contain at least four projects in a new solution:

MyAspireApp.AppHost: The main entry point for the application.
MyAspireApp.ServiceDefaults: A library of default services and configurations.
MyAspireApp.Web: A Blazor web frontend.
MyAspireApp.ApiService: An ASP.NET web API backend service.

Installing the Aspire CLI

Okay, now that we have the Aspire projects set up, there's one more thing we might want: the aspire CLI. The aspire CLI is a preview tool that simplifies application startup. To install it, you can run the following command:

dotnet tool install --global aspire.cli --prerelease

After installing the CLI, you can run the aspire --help command to see usage and available options. Effectively, this CLI is a wrapper around the dotnet run command that removes the need to specify the --project option. It will automatically find the AppHost project in your solution and run it.

Next Steps

At this point, you should have the Aspire projects you want in your solution and the aspire CLI installed. You can now start modeling your application in the AppHost project and customize the ServiceDefaults project to fit your needs.

.NET Options Pattern: Binding settings and user secrets

Victor Frye — Wed, 25 Jun 2025 12:41:56 +0000

Configuration management is a crucial aspect of building applications. Whether locally or in the cloud, you need a way to manage settings and secrets without hardcoding values everywhere. In .NET, the options pattern is a powerful out-of-the-box approach to binding configuration values from just about any source, including JSON files, environment variables, user secrets, and even cloud configuration providers.

In this article, we'll explore the .NET options pattern, how to set it up in your application, and some key features for flexibility in your application.

What is the Options Pattern?

The options pattern is a .NET design pattern that provides a way to bind configuration values to strongly typed classes. This allows us to take advantage of object-oriented programming principles, such as type safety and separation of concerns, while also extracting values from various configuration stores. In .NET, the options pattern is implemented through the Microsoft.Extensions.Options and Microsoft.Extensions.Configuration libraries, already included in frameworks like ASP.NET Core, and the base IOptions<TOptions> interface.

I consider the options pattern table stakes for any .NET application as it cleanly separates application code from configuration. Local development can use JSON files and user secrets, while production can use remote configuration stores like Azure App Configuration and Key Vault, all without changing your code. You can even mix and match local and remote sources for dev/test integrated local development. This flexibility significantly improves developer productivity and application maintainability.

Setting Up the Options Pattern

To get started with the options pattern, you need 3 things:

A settings class that represents the configuration values you want to bind.
A configuration source, such as your appsettings.json file or user secrets.
A binding and registration of the settings class.

In this example, we'll be binding a simple settings class for configuration values related to calling a downstream API. You can find the complete code for this example in the GitHub repository.

The Settings Class

When defining your settings classes, you will want to split apart your settings based on their consumption. This allows us to separate the concerns of different parts of our application configuration and later will make it easier to consume using dependency injection. In this case, we have only one settings class named PlaceholderApiSettings that contains a base URL, an API key, and an optional version number:


using System.ComponentModel.DataAnnotations;

public sealed class PlaceholderApiSettings
{
    internal const string SectionName = $"{nameof(PlaceholderApiSettings)}";

    [Required]
    public required Uri BaseUrl { get; set; }

    [Required]
    public required string ApiKey { get; set; }

    public string Version { get; set; } = "v1";
}

You will notice that we also have a constant for the section name. Since we might have multiple settings classes, it is a good idea to define sections in our configuration to avoid overlapping settings. Additionally, we are using the Required attribute and required keyword to denote we expect these properties to always be set, whether via constructor or binding. These are all optional elements.

The requirements for a settings class are simple: we need field names that express our expected configuration sources to also use.

The Configuration Sources

The options pattern binds configuration values from any source supported by Microsoft.Extensions.Configuration. That includes:

Your appsettings.json file
Environment variables
.NET Secrets Manager (aka user secrets)
Azure App Configuration
Azure Key Vault
And more!

For our example, we will use the appsettings.json file and user secrets. Recalling our section name in the settings class, we can define a section and two field values in our appsettings.json file like this:

{
  // Other configuration settings...
  "PlaceholderApiSettings": {
    "BaseUrl": "https://jsonplaceholder.typicode.com/todos",
    "Version": "v1",
  }
}

We can nest our settings under our section name or nest that under further prefixes for any settings we may want to group together. We are creating a fully qualified path to each setting field for any configuration source we bind equivalent to what we are expecting, PlaceholderApiSettings:BaseUrl for example. This value might differ by environment, but as long as we have one value set per environment by any configuration source available in that environment, we can bind it to our settings class.

Sometimes we have sensitive information that we don't want to commit in source code. Here, we can use the .NET Secrets Manager to store and still bind sensitive values like API keys. To do this, we can use the dotnet user-secrets command group in the dotnet CLI. If you haven't already initialized user secrets for your project, you can do so with the following command:

dotnet user-secrets init --project "Path/To/Your/Project.csproj"

This command will add a UserSecretsId property to your project file, which uniquely identifies your project. This ID allows you to store secrets safely outside of your source code.

From here, we can now add our API key to the secrets file with the following command:

dotnet user-secrets set "PlaceholderApiSettings:ApiKey" "SuperSecretApiKey123" --project "Path/To/Your/Project.csproj"

This command will create or update the secrets.json file with the key-value pair for our API key. The resulting file will look something like this:

{
  "PlaceholderApiSettings:ApiKey": "SuperSecretApiKey123"
}

Now we have two configuration sources with the various values set.

Binding the Options

The final step towards setting up the options pattern is binding and registration of our settings class. This is where the Microsoft.Extensions.Options library comes into play. In our Program.cs entry point, we need to add the options, configure the binding source, and, optionally, validate the settings to ensure they meet our expectations. To do this, we can use the AddOptions, BindConfiguration, and ValidateDataAnnotations method chain on the IServiceCollection:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddOptions<PlaceholderApiSettings>()
                .BindConfiguration(PlaceholderApiSettings.SectionName)
                .ValidateDataAnnotations();

// Registration of other services and configuration...

var app = builder.Build();

// The rest of your application setup...

await app.RunAsync();

The AddOptions<T> method gets the options builder for our settings class, allowing us to configure it. The BindConfiguration method takes the section name from our settings class, telling the options builder the configuration section path to bind to (in this case, PlaceholderApiSettings:*). Finally, the optional ValidateDataAnnotations method tells the options builder to use the data annotations we defined to validate the values during binding. You can use other validation methods, such as ValidateOnStart or Validate to perform validation at different times or with custom logic. The key is we have a strongly typed settings class and a section path that aligns with the keys in our various configuration sources.

After this setup, we now have multiple new classes registered in our dependency injection container that we can use to access our settings.

Consuming the Options

We have defined our settings class, configured our sources, and bound our options. Now we need to consume them in our application. The options pattern has already three interfaces implemented that we can use to access our settings:

IOptions<T>: A singleton instance bound with the settings values at start up.
IOptionsSnapshot<T>: A scoped instance that can be used to access settings in transient or per-request services and can be configured to reload on changes.
IOptionsMonitor<T>: A singleton instance that can be used to access settings singleton scenarios and also supports change notifications.

Instances of all three interfaces are pre-configured in our dependency injection container by the AddOptions method chain and can be used in any service through constructor injection. The base use case is the IOptions interface, though the later two support advanced scenarios like refreshing settings during runtime. In our example, we will use the IOptions<PlaceholderApiSettings> to access our settings in client class for our placeholder API.

Using dependency injection, we can retrieve our settings now like this:

using Microsoft.Extensions.Options;

public class PlaceholderClient(IOptions<PlaceholderApiSettings> options)
{
  private readonly PlaceholderApiSettings _settings = options.Value;

  // Omitted methods for brevity
}

Through constructor injection of the options interface of our choice, we can access the bound settings class and all its members through the Value property. Now, we can use the _settings field to access any of the properties we defined include the base URL from our JSON source and API key from our user secrets source in this PlaceholderClient.

Conclusion

The .NET options pattern is a simple, unified way to manage and consume configuration values in our applications. By defining custom settings classes, we get the benefits of type safety and the separation of concerns. We are able to consume values from multiple configuration sources like our application settings or user secrets locally and remote configuration stores like Azure App Configuration or Key Vault in the cloud. Finally, by binding our settings to configuration paths, we can easily access them through dependency injection and reap the benefits of inversion of control in our application. All together, this design pattern offers a flexible foundation for managing configuration values in .NET applications.

If you want to explore more about the options pattern, you can find additional resources and extensions in the official Microsoft Learn documentation.

Microsoft Build 2025 Wrapped

Victor Frye — Thu, 22 May 2025 16:10:55 +0000

Microsoft Build 2025 has come and gone, and it has been a whirlwind of announcements, a buzzword storm of AI, and some hidden gems that you might have missed. Let's attempt to wrap up the highlights according to myself, your friendly neighborhood developer.

AI Everywhere

Microsoft Build 2025 was all about artificial intelligence, with nearly every session including the words "AI", "MCP", or "Copilot". Whether we like it or not, AI is the current trend and Microsoft is all in. The company is integrating AI into nearly every product, from Azure to VS Code, and from Windows to .NET Aspire! That's right, even my favorite new .NET framework is getting the AI treatment. Not only were the sessions all about AI, but the keynote and announcements also had a heavy focus on intelligence and Copilot additions up and down the technology stack. Some of these need their own blog posts, but here are some of the highlights:

GitHub Copilot Coding Agent: A new feature that allows developers to assign tasks to Copilot in the GitHub platform.
GitHub Copilot for .NET Aspire: The Aspire dashboard now includes Copilot integration, allowing developers to chat with Copilot with Aspire context.
NLWeb: A new protocol built on top of MCP that allows for natural language to be a first-class citizen in web development.
Azure AI Foundry: New enhancements to Azure AI Foundry, including Foundry Local in preview—which brings models to your local machine—and Foundry Agent Service going to general availability.

I want to focus on the first two items here as they are the two I am closest to and the most excited about.

GitHub Copilot Coding Agent

GitHub Copilot continues to evolve with the introduction of the new Coding Agent. This allows developers to assign development tasks to Copilot in GitHub. From there, Copilot takes over the developer inner loop and handles writing code, running tests, and drafting a pull request to integrate the changes. You can watch the PR draft in real-time to see the changes Copilot pushes and collaborate through comments to suggest changes. It even allows control over the MCP servers used in the development process. This sounds like the automated software engineer pitch, but instead it is being pitched for the tedious work developers often need to do, e.g. upgrading your .NET 8 project to .NET 10 this fall. It is in preview now, but requires a GitHub Copilot Pro+ or Enterprise license currently. Neither of which I have as they are expensive at $390 a year. I might need to review my training budget...

GitHub Copilot for .NET Aspire

Yeah that's right, .NET Aspire is getting the Copilot treatment too! When launching the app from Visual Studio or Visual Studio Code, you will now see the familiar GitHub Copilot icon in the top right corner of the Aspire dashboard. Using it to test my own website, I asked it get traces and structured logs and it was able to identify that no telemetry exists but my web client application was in the running state. That's correct as I haven't configured any telemetry with the Next.js frontend just yet... I have been meaning to get to that.

Immediately, I am both impressed and annoyed. Will I use Copilot here? Probably, given work where I can use GitHub Copilot professionally and we are utilizing .NET Aspire. However it does not work when running from the dotnet CLI nor the aspire CLI. For me, this is a big miss even if it is a technical limitation as I am a command-line enthusiast and my workflows start in the terminal. Secondly, the AI-ification of .NET Aspire means more people may be turned off by the product due to AI fatigue in the industry. But for those fatigued and who want nothing to do with GitHub Copilot, you can disable it, thankfully. You can set the ASPIRE_DASHBOARD_AI_DISABLED environment variable to true in the app host launchSettings.json file to hide all Copilot UI elements.

{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "profiles": {
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:17168;http://localhost:15027",
      "environmentVariables": {
        // ... other environment variables
        "ASPIRE_DASHBOARD_AI_DISABLED": "true" // Disable GitHub Copilot in Aspire
      }
    }
  }
}

Open Source Commitments

Microsoft continues to be a major contributor to open source and announced a couple major projects moving from closed-source to the open on GitHub. The first is a long-time coming project, the Windows Subsystem for Linux (WSL). I first used WSL to port a Java stack to Windows. That stack was a nightmare to run on Windows due to a team optimizing for macOS workflows but we wanted to enable new developers to use standard Windows dev machines and stop requiring expensive macOS hardware for a cross-platform native toolchain like Java. Today, WSL is a major part of the Windows developer experience. And now, Microsoft is open-sourcing WSL to allow the community to contribute and innovate on the project on GitHub.

Another major project moving to open source is the GitHub Copilot Chat extension for Visual Studio Code. As more and more IDEs and text editors are adding AI features, the Copilot Chat extension is being moved to open source AND the code being integrated into the Visual Studio Code core codebase. This means the main AI UI experience for Visual Studio Code will become a first-class component of VS Code. Personally, I am excited about this as pushes the AI developer experience towards transparency and competing with other juggernauts like Cursor and Windsurf. This is also another blurred line between the GitHub org and the developer division at Microsoft. It is a small step, but a step in the right direction.

New Command Line Editor

A small footnote in the book of news and not mentioned in the keynote is my favorite announcement from Build: Edit. It is a command line text editor, similar to Neovim or Emacs, that pays homage to the classic MS-DOS editor with modern inspiration from VS Code. Edit allows for a modeless command-line interface, meaning you do not have to switch between command and edit modes like in Neovim. This makes it far easier to use for new developers or those unfamiliar with command-line workflows. I have already dropped it into my inner loop in favor of Neovim. There are a couple kinks to work out, but I see a ton of potential and community input to the app. It is already available to install via WinGet and launched with binaries for Windows and Linux. The source code is available on GitHub, and issues and pull requests are already open for various features including macOS support and additional localization support.

Closing Thoughts

Microsoft Build 2025 was a whirlwind and a lot to digest. There was a ton of AI innovation, some open source announcements, and cool new tools like Edit released. Like every year, where any of these new technologies go is up to community adoption and may change over time. It is also hard to catch everything, so I recommend you check out the Book of News for a full list of announcements from Build. I look forward to seeing which of these technologies resonate with others. Until then, happy coding!

Multi-Stage Docker Builds: A .NET developer's guide

Victor Frye — Mon, 12 May 2025 17:34:02 +0000

My Docker skills were getting rusty. My day-to-day work has shifted away from containerized workloads and more towards modernizing legacy systems or architecting serverless solutions. Somehow, I've also never drafted my own Dockerfile from scratch. Docker and containers are culturally synonymous, and both are core cloud native technologies that any modern developer should be familiar with. So, I decided to write my own multi-stage build for a .NET web API for fun. This post will explore the results and guide you based on my learnings.

For this post, I will be using .NET 10 in preview. The application is a simple web API with a single endpoint that returns "Hello, .NET!". You can find the code for this here on GitHub.

What is a multi-stage build?

A traditional Dockerfile might follow the same pattern as a pipeline: You install your tooling, check out your source code, and build your artifacts. It might look something like this:

FROM mcr.microsoft.com/dotnet/sdk:10.0-preview-alpine
WORKDIR /source

COPY src/WebApi/WebApi.csproj src/WebApi/
COPY test/Tests/Tests.csproj test/Tests/
COPY VictorFrye.HelloDotnet.slnx ./
RUN dotnet restore

COPY . .
RUN dotnet build -c Release --no-restore 

RUN dotnet test -c Release --no-build

RUN dotnet publish ./src/WebApi/WebApi.csproj -c Release --no-build -o /app

WORKDIR /app
USER $APP_UID
ENTRYPOINT ["dotnet", "VictorFrye.HelloDotnet.WebApi.dll"]

The problems with this approach are multifold. Firstly, the image is large. It is over 2 GB as it contains all the build artifacts, including the .NET SDK and all the source code. The massive means you take a performance hit as the size corresponds to longer build and deploy times and is more expensive for storage and network transfers. Additionally, this is a security risk, as it exposes your source code which may contain intellectual property or sensitive information. We can optimize this all by using a multi-stage build.

Notice our first Dockerfile includes exactly one FROM statement. This means we reused the same base image for our build and runtime. In a multi-stage build, we use multiple FROM statements to separate our stages. This results in distinct images for our build and for production runtime. The build image will utilize the full .NET SDK and all of the source code. The runtime image will only include the ASP.NET runtimes and the artifacts we need to run our application. This results in a smaller production image, faster to build and deploy and with a reduced attack surface.

Writing the multi-stage Dockerfile

The first thing we need to do is decide on our base images. For production, I know this is an ASP.NET web API and want to keep it slim. We do not want the SDK included and only need that ASP.NET runtime and its dependencies for. As for our Linux flavor, Alpine is my go-to choice as it's stripped down to the essentials and security minded. Keep in mind that Alpine is not always the best choice for every application. Thus, I will be using the mcr.microsoft.com/dotnet/aspnet:10.0-preview-alpine image for our production base image. For our build image, we want to align architecture to production but need the full .NET SDK. This means we will use the mcr.microsoft.com/dotnet/sdk:10.0-preview-alpine image. For deciding on yours, I recommend browsing the Microsoft Artifact Registry.

FROM mcr.microsoft.com/dotnet/aspnet:10.0-preview-alpine AS base
LABEL com.github.owner="victorfrye"
LABEL com.github.repo="hellodotnet"
USER $APP_UID

FROM mcr.microsoft.com/dotnet/sdk:10.0-preview-alpine AS build
WORKDIR /source

Notice the AS keyword and the names we have assigned. This is how we can reference our stages later. In the production base, we can set additional production configurations including the USER or add labels. Now that we have our base images, we can start to compile our application.

For our build, we first need to install our dependencies and run a dotnet restore. To do this, we need to copy our solution and project files into the build image. Remember Docker uses layers and caching to optimize images so small steps in our build create efficiencies.

COPY src/WebApi/WebApi.csproj src/WebApi/
COPY test/Tests/Tests.csproj test/Tests/
COPY VictorFrye.HelloDotnet.slnx ./
RUN dotnet restore

Next, we need to copy the rest of our source code into the build image and build our binaries for release. We also want to explicitly ensure we are not repeating the previous steps.

COPY . .
RUN dotnet build -c Release --no-restore

At this point we are wrapping up our initial build stage. Our builder still needs to run our tests and publish, but like a pipeline we can separate these into their own stages. This is good practice as it allows Docker to fail fast and create a logical separation of concerns. Our next stage will be our test stage and use the build stage as its base. It will execute our tests without rebuilding and fail the image builder if they do not pass.

FROM build AS test
RUN dotnet test -c Release --no-build

Now we can move on to our final builder stage: publish. This stage will use the test stage including the previous build and test steps. We need to reference the test stage to ensure the full chain of events is executed. The goal of publishing is to output the compiled binaries and dependencies to a directory. They are the artifacts our application needs to run in production. We want to be explicit about our output directory as we will use it in our final image.

FROM test AS publish
RUN dotnet publish ./src/WebApi/WebApi.csproj -c Release --no-build -o /out

We are almost done! We have our entire builder and within it the artifacts we want. Our builder now ensures a repeatable process and environment for portable consistency. The last step is to copy our artifacts to our production base image as our final stage. We will be using that base stage we defined at the beginning and copying the artifacts from the publish stage. We will then be setting our application entry point to the compiled DLL artifact for our application.

FROM base AS final
WORKDIR /app
COPY --from=publish /out .
ENTRYPOINT ["dotnet", "VictorFrye.HelloDotnet.WebApi.dll"]

The final result

Putting all our stages together, we still have a single Dockerfile. My result looks like this:

FROM mcr.microsoft.com/dotnet/aspnet:10.0-preview-alpine AS base
LABEL com.github.owner="victorfrye"
LABEL com.github.repo="hellodotnet"
USER $APP_UID

FROM mcr.microsoft.com/dotnet/sdk:10.0-preview-alpine AS build
WORKDIR /source

COPY src/WebApi/WebApi.csproj src/WebApi/
COPY test/Tests/Tests.csproj test/Tests/
COPY VictorFrye.HelloDotnet.slnx ./
RUN dotnet restore

COPY . .
RUN dotnet build -c Release --no-restore 

FROM build AS test
RUN dotnet test -c Release --no-build

FROM test AS publish
RUN dotnet publish ./src/WebApi/WebApi.csproj -c Release --no-build -o /out

FROM base AS final
WORKDIR /app
COPY --from=publish /out .
ENTRYPOINT ["dotnet", "VictorFrye.HelloDotnet.WebApi.dll"]

This includes multiple stages but benefits from a smaller production image size of 167.5 MB, down from our initial 2 GB! That is over a 80% reduction in size and includes none of the source code or build artifacts. It also benefits from faster build times as changes to various stages only require rebuilding the subsequent stages. My favorite part is how similar the structure is to a non-containerized pipeline or GitHub Actions workflow. You move from setup to build to test to publish to production-ready artifacts.

Writing this Dockerfile was a fun exercise and preparation for me in working heavily with Docker again. Hopefully, it also helps you understand the mental process, structure, and benefits of a multi-stage build.

Hello .NET Aspire: Breaking down the key features

Victor Frye — Wed, 07 May 2025 19:59:22 +0000

.NET Aspire is the latest framework from Microsoft in the .NET ecosystem, adding to ASP.NET, Blazor, Entity Framework, MAUI, etc. Released in 2023, it was designed specifically for cloud-native and distributed applications and acts as an orchestrator for the entire application stack. It is opinionated, meaning it provides a set of conventions and best practices for how to build applications. If you adopt these opinions, Aspire makes the developer experience much smoother and more productive. Some of these key features include:

Application modeling: Aspire allows you to model your application in C# code instead of using YAML or other configuration languages.
Local development: It provides a seamless local development experience, allowing you to start and stop your entire application with a single command.
Opinionated service defaults: It provides a set of default configurations and settings for common cloud-native concerns, which can be extended or overridden as needed.
Client integrations: Aspire includes client libraries and SDKs for common cloud-native services, making it easier to integrate your application with dependencies locally and in the cloud.
Automated testing: Aspire can be used with existing test frameworks to spin up and tear down your entire application stack for integration or functional tests.

In this post, I will provide some background on Aspire and overview of its key features.

Brief history so far

At the initial launch of Aspire, the communication was obtuse about the purpose of this new framework. It was described as "an opinionated, cloud ready stack for building observable, production ready, distributed applications." This was a bit vague and left many developers including myself wondering what exactly it offered. However, as others including myself started to play with it, we quickly realized it was an exciting new way to manage the complexity of building modern applications.

Since then, the Aspire team has been quickly evolving the framework and adding new features based on community reception. This has led to features like the Aspire.Hosting.Testing package for automated testing and the upcoming Aspire CLI.

Support and updates

Aspire is unique in that most of the features are not used in production but instead are used during the local development process and help prepare for production. Additionally, the Aspire team is releasing new features and updates at a rapid pace as a new framework. Because of this, Aspire and the team at Microsoft are shipping updates to Aspire multiple times a year and only the latest version of Aspire is currently supported. This is a culture shock for many .NET developers familiar with the LTS/STS yearly releases of .NET but as we explore what Aspire is and how it works, you will see this is a good thing and introduces minimal risk to your production applications.

Key features of Aspire

Application modeling

Aspire provides a set of abstractions and patterns for modeling your application in C# code. This significantly differs from alternatives like Docker Compose where YAML is used to define your model. The C# code-first approach feels more natural for .NET developers and allows for a similar experience to how you write other application configuration features for startup or dependency injection, but now modeling your external and distributed dependencies.

Using a new AppHost project in your solution, you can model the makeup of your distributed application. Below is a sample Program.cs that includes a ASP.NET Web API, SQL Server database, and Redis cache.

var builder = DistributedApplication.CreateBuilder(args);

var sql = builder.AddSqlServer("sql")
                 .AddDatabase("db");

var cache = builder.AddRedis("cache");

builder.AddProject<Projects.WebApi>("api")
       .WithReference(sql)
       .WaitFor(sql)
       .WithReference(cache)
       .WaitFor(cache)
       .WithExternalHttpEndpoints();

await builder.Build().RunAsync();

The app host project also includes a .csproj file includes a reference to the Aspire SDK and hosting integrations unique to Aspire. A sample .csproj file for the above app host project might look like this:

<Project Sdk="Microsoft.NET.Sdk">

  <Sdk Name="Aspire.AppHost.Sdk" Version="9.2.0" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <UserSecretsId>{{SomeGuid}}</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\WebApi.csproj" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Aspire.Hosting.AppHost" Version="9.2.0" />
    <PackageReference Include="Aspire.Hosting.Redis" Version="9.2.0" />
    <PackageReference Include="Aspire.Hosting.SqlServer" Version="9.2.0" />
  </ItemGroup>

</Project>

These two key files make up the heart of Aspire's core feature: the app host.

Local development

Aspire provides a local development experience that is similar to how you would run your application in the cloud. This includes support for containerized services and executable workloads traditionally outside the .NET ecosystem. For example, you can run a PostgreSQL database, Java backend, and JavaScript frontend by starting the Aspire app host project with or without any other C# code in your solution. You get a dashboard for visualizing your application stack and a unified way to start and stop the entire distributed system.

With our app host project, we have a new entry point for our local application that can start up entire application stack. With the press of F5 in Visual Studio or running dotnet run against our app host project, all resources defined in the application model will start up and be available for use. For our sample app, this includes the ASP.NET Web API, a SQL Server database, and Redis for caching. The app host project also provides a dashboard for visualizing your application stack and managing the lifecycle of your services.

Our dashboard will look something like this:

This dashboard provides a visual representation of our application stack resources, console logs, and telemetry data for each of the services. It becomes the central UI hub for exploring our local app.

Opinionated service defaults

Aspire provides a set of default configurations and settings for common cloud-native concerns including instrumentation, monitoring, and service discovery. These defaults are defined once in a new project and then applied to other projects in the solution. You can extend, override, or opt-out of these defaults as needed, but the goal is to provide a set of best practices that you can follow to get started quickly.

The service defaults are a second new project type in your solution. This shared project, commonly named ServiceDefaults, includes a .csproj file and a single Extensions.cs file. The project is then referenced by your application projects. The Extensions.cs file includes default configurations for:

OpenTelemetry: Adds OpenTelemetry SDK services including logger, metrics, and tracing. Additionally, it configures the OpenTelemetry Protocol (OTLP) exporter for sending data to a collector.
Health Checks: Adds two default health check endpoints: /health and /alive. The former includes predefined checks from hosting integrations, while the latter simply responds if the application is running.
Service Discovery: Turns on service discovery by default with services for dependency injection and in the http client builder.
Http Client: Adds resiliency defaults using Polly for all HttpClient instances.

These defaults are exported as two extension methods AddServiceDefaults and MapDefaultEndpoints that can be called while building your .NET application as shown below:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddServiceDefaults();
// ... existing service configuration

var app = builder.Build();
app.MapDefaultEndpoints();
// ... existing app configuration

await app.RunAsync();

Client integrations

Aspire provides a set of client libraries and SDKs for common cloud-native services, such as SQL Server, Redis, Azure Service Bus, and OpenAI. These libraries are designed to seamlessly integrate your application with dependent services locally and post-deployment. This allows you to focus on writing your application code without worrying about the underlying infrastructure.

Some of the client integrations include:

SQL Server
Redis
Azure Service Bus
Azure Blob Storage
Azure OpenAI
Ollama

These client integrations are added to your application project via NuGet packages. For example, to add the Entity Framework SQL Server integration you might run the following command:

dotnet add package Aspire.Microsoft.EntityFrameworkCore.SqlServer

Automated testing

As an orchestrator for your local environment, Aspire can spin up and tear down your entire application stack for automated testing. Using the Aspire.Hosting.Testing package and your existing test framework, you can write integration or functional tests in C# that run against your actualized application in the same environment as you develop in. This allows you to test your application in more realistic scenarios and catch issues earlier in the local developer process instead of waiting for a deployment to a staging or production environment.

Conclusion

Aspire is an exciting new addition to the .NET ecosystem. It is actively evolving and has a lot of potential to simplify the developer experience locally and in the path to production. If you have not already, I highly encourage you to try adding it to your existing projects or start your next with it. If you are interested in learning more, follow along as I explore the framework in more detail in future posts. I will be diving into specific features such as the application host, extending service defaults, and integration testing. Or, if you cannot wait, check out the Aspire on Microsoft Learn for official documentation.