Aspire agnostic

[cesarbmx]

I don't want to pollute my projects with Aspire nugets nor ServiceDefaults methods.
I just want to provision the containers (using Aspire) in a separate project exactly as I was doing with docker compose.

[davidfowl]

What's stopping you from doing that?

[cesarbmx]

Thanks for the reply.
I promise, I've gone through all the documentation but still having difficulties understanding the main purpose of Aspire.

Dashboard
The Dashboard looks nice. However, is it only for local development? Aren't we reinventing the wheel here?
We already run Kibana, Elasticsearch, Redis etc via docker-compose in all environments, including local.

Infrastructure provisioning
I personally hate yml files in docker-compose. The first time I heard about Aspire, I was happy to find out a "typed" alternative that can output the deployment manifest for me. Unfortunately, Aspire adds a strong dependency to my projects via hosting packages forcing me to change, for example, the previous Redis configuration with a wrapped one based on Aspire. This is something that does not happen with docker-compose.

Deployment
I wonder how Aspire eases CI/CD processes with Azure Pipelines.

Conclusion
Integrating Aspire in our current projects just for development purposes isn't justified.

"Aspire isn't designed for deploying - it's designed to make developing easy".

[davidfowl]

The Dashboard looks nice. However, is it only for local development? Aren't we reinventing the wheel here?
We already run Kibana, Elasticsearch, Redis etc via docker-compose in all environments, including local.

The Aspire dashboard is easier to setup than most of these other telemetry systems that are not optimized for local development. It's easy much easier to use than most other tooling. In the production case, it's much more nuanced. It's more of a "just in time/live" view of telemetry (as there's no storage).

I personally hate yml files in docker-compose. The first time I heard about Aspire, I was happy to find out a "typed" alternative that can output the deployment manifest for me. Unfortunately, Aspire adds a strong dependency to my projects via hosting packages forcing me to change, for example, the previous Redis configuration with a wrapped one based on Aspire. This is something that does not happen with docker-compose.

The apphost project is a .NET project, if you're uncomfortable with a .NET project then the idea of aspire may not appeal you to. Having a single place to hit F5 in a solution that just works is pretty powerful. Early customers of aspire are really happy with the ability to codify requirements for what a project needs to run successfully (this reduces onboarding time dramatically).

The Aspire.Hosting.* packages are super powerful as it is an example of allowing you to abstract configuration for a specific resource. You can even build your own.

These packages live in the application host, not in your service projects.

I wonder how Aspire eases CI/CD processes with Azure Pipelines.

The docs show an example of deploying to azure using azd and github actions or azure dev ops:

https://learn.microsoft.com/en-us/dotnet/aspire/deployment/azure/aca-deployment-github-actions

Integrating Aspire in our current projects just for development purposes isn't justified.

That's a fine conclusion to come to. We're here to answer any questions you might have about the project.

[cesarbmx]

@davidfowl Thank you very much for the detailed answers and references.