Frequently asked questions about .NET Aspire

Docker Compose is excellent but is unproductive when all you want to do is run several projects or executables. Docker Compose requires developers to build container images and to run apps inside of containers. That's a barrier when you just want to run your front end, back end, workers, and a database. With .NET Aspire, you don't need to learn anything beyond what you already know.

Configuration through declarative code is better than through YAML. Docker Compose gets complex once you attempt to do any form of abstraction or composition (for example, see the old eshopOnContainers app). In addition, there are environment variable replacements (and includes) and no types or IntelliSense, and it's hard to reason about what exactly is running. Debugging is also difficult. .NET Aspire produces a better experience that's easy to get started and scales up to an orchestrator like Compose using a real programming language.

You can manually add projects to your .NET Aspire solution by using the builder.AddProject("<name>", "<path/to/project.csproj>") API.

.NET Aspire doesn't constrain deployment of any existing project or solution. .NET Aspire exposes a deployment manifest that's used by tool authors to produce artifacts for deployment to any cloud provider. However, unfortunately, not all cloud providers offer tooling for deployments based on this manifest. The manifest is a simple JSON file that describes the resources of your app and the dependencies between them. The manifest is used by the Azure Developer CLI to deploy to Azure. Likewise, Aspir8 uses the manifest to deploy to Kubernetes. You can use the manifest to deploy to any cloud provider that supports the resources you're using.

Yes, you can build .NET Aspire apps without using any Azure-proprietary dependencies. While .NET Aspire does offer a first-party solution to deploying to Azure, it's not a requirement. .NET Aspire is a cloud-native stack that can be used to build applications that run anywhere. All Azure-specific offerings are explicitly called out as such.

.NET Aspire service discovery APIs are an abstraction that works with various providers (like Kubernetes and Consul). One of the big advantages is that it works locally and is backed by .NET's IConfiguration abstraction. This means you can implement service discovery across your compute fabric in a way that doesn't result in code changes. If you have multiple Kubernetes clusters or services on Azure App Service or Azure Functions, you don't have to fundamentally change your application code to make it work locally, either in a single cluster or across multiple clusters. That's the benefit of the abstraction.

.NET Aspire takes a big bet on .NET's integration with OpenTelemetry. The .NET Aspire dashboard is a standard OTLP server that visualizes various telemetry data. Leaning on these open standards makes it easy to build these things without breaking compatibility with the broader ecosystem.

.NET Aspire isn't a replacement for these tools, but rather a complementary technology. .NET Aspire is a set of libraries and tools that make it easy to build applications that are observable. For more information, see the Metrics example in the .NET Aspire sample repository that shows Grafana and Prometheus.

.NET Aspire isn't a framework, it's an opinionated stack. Perhaps the most controversial parts of it are the DistributedApplication APIs that you can use to build up the orchestration model in any .NET-based language. While everything is possible today, it's not easy. Using the Unix philosophy, the entire cloud-native ecosystem is built around tying various pieces of CNCF software together to build a stack. .NET Aspire tries to do the same thing using learnings from the cloud-native space and picks some opinions (in ways that use the same building blocks). One novel thing about how .NET Aspire builds various pieces of the stack is that it doesn't restrict the access or compatibility of other applications, frameworks, or services. As people play with it more, they realize how composable and extensible it is.

Microsoft Orleans and .NET Aspire are complementary technologies.

Orleans is a distributed actor-based framework. .NET Aspire is a cloud-ready stack for building observable, production-ready, distributed applications. It includes local orchestration capabilities to simplify the developer inner loop and reusable opinionated components for integrating with commonly used application dependencies. An Orleans-based solution will still have external dependencies such as data stores and caches for which .NET Aspire can be used for orchestration purposes.

For more information, see Use Orleans with .NET Aspire and the corresponding Orleans voting app sample.

Dapr and .NET Aspire are complementary technologies.

Where Dapr abstracts some of the underlying cloud platform, .NET Aspire provides opinionated configuration around the underlying cloud technologies without abstracting them. A .NET-based application that uses Dapr can use .NET Aspire to orchestrate the local developer inner loop and streamline deployment. .NET Aspire includes extensions that support the launching of Dapr side-car processes during the inner loop.

For more information, see Use Dapr with .NET Aspire and the corresponding Dapr sample app in the .NET Aspire sample repository.

Project Tye was an experiment which explored the launching and orchestration of micro-services and support deployment into orchestrators such as Kubernetes. .NET Aspire is a superset of Tye which includes the orchestration and deployment capabilities along with opinionated components for integrating common cloud-native dependencies. .NET Aspire can be considered the evolution of the Project Tye experiment.

.NET Aspire provides components that rely on the Azure SDK for .NET, to expose common functionality for storage (Azure Blob Storage, Azure Storage Queues, and Azure Table Storage), databases (Azure Cosmos DB and Azure Cosmos DB with Entity Framework Core), messaging, and security.

.NET Aspire makes it easy to develop distributed applications that can be orchestrated on your local development environment as executables and containers. Kubernetes is a technology that orchestrates and manages containers across multiple machines. .NET Aspire projects can produce a manifest that tool authors can use to produce artifacts for deployment to Kubernetes. In essence, Kubernetes is a deployment target for .NET Aspire projects.

Yes, worker services are fully supported and there are docs and samples available to help you get started. Worker services are a great way to run background tasks, scheduled tasks, or long-running tasks in .NET Aspire. For more information, see Database migrations with Entity Framework Core sample app.

We have no specific support for Azure Functions thus far in .NET Aspire, however it's a target execution environment for deployment that we are planning to support in future.

No. .NET Aspire doesn't support running web apps on IIS or IIS Express.

No. .NET Aspire doesn't support deploying apps to IIS. However, it doesn't prevent you from deploying your apps to IIS in the same way that you always have.

.NET Aspire integrations require specific configuration that must be provided manually. The same is true for Service Discovery, ideally, you should deploy to something other than IIS.

Next steps

To learn more about networking and functions:

• .NET Aspire overview
• Build your first .NET Aspire project
• .NET Aspire components