Exciting work,@davidfowl . I'm not using this professionally yet, but have been tracking the docs and news for a while. Your team is working hard. Keep it up!

Amazing stuff. Native support for Multi-Repo setups (amongst other items listed) would be a game changer for my company and existence applications. Great work keep it up.

Focusing on JavaScript for polyglot experience, hope Azure Static Web Apps make it on deployment targets roadmap.

That said, I'm so excited to see where Aspire is and is going.

Being able to have some projects not start immediately at launch time and then to be able to start them up as needed would be amazing. I sometimes add standalone console apps to seed data or apply a specific API load and I don’t always want those to start at launch time.

so cool! absolutely love the polyglot and deploy anywhere part, also recentaspire publish...

Storage dashboard support is great; it would be an excellent feature for a hobby project to run an Aspire dashboard with persistent storage.

Not sure how feasible is but I'd love if the dashboard didn't stop working when the apphost project is stopped so that we can keel exploring the data (traces and more) collected until that point.

Something I worked on last night was trying to get a .NET Framework project (WCF) to run as part of an Aspire solution. Whilst I can reference it in the AppHost successfully, I can’t get it to run in debug, my assumption is due to the IIS Express host. Whilst I understand this is not a priority, I think this is a great use case for teams applying the strangler pattern to get rid of older tech in their organizations, as a stepped migration approach. I see that there has been some development here already in the community space, but there still seems to be a number of gaps around connecting OTEL.

The plans for Azure Pipelines got me thinking:

We run our pipelines with specific Entra Service Principals to limit the impact of changes. Would this be something we can configure as part of the pipeline definition phase?

Isaspire.dev supposed to display some informations? (Official docs, samples, and walkthroughs.)

Is it planned in the future as a home for Aspire?

Would running. Net Framework projects from the apphost be supported?

Built-in Runtime Acquisition – Automatically installs the runtime required to bootstrap various dependencies (node, python, .NET, java etc)

On the surface-level this sounds good, but there are some details here that I consider make-or-break. If it functions like hownix does it then it's a great idea. If it works like basically anything else then I'd personally never use it (And just continue using Nix as I currently am).

That is to say, is the plan to install the dependencies locally (sym-(or even hard-)linked into/.aspire*), or is the plan to install the dependencies globally (In a semi-arbitrary location as decided by the ecosystem (~/.dotnet for .Net, etc..).

Personally I really dislike automated global installs, as generally speaking they're very annoying to uninstall as the tooling that installs it has their own quirky conventions. Like, whenever I get a new computer the very first thing I have to do before installing JetBrains Rider is manually installing .Net to ensure that it doesn't install an arbitrary version of .Net in some non-default location.

TLDR: Uninstalling programs should beeasier than installing them not harder, as it is with more-or-less all systems I've ever used beside Nix.

* and hook that into the integrations (so instead ofnpm run [...] you use/.aspire/tools/node24.4.1/npm run [...].

I would suggest to use user-replaceable templates for some features, in particular for CI/CD pipelines. It will hugely facilitate enterprise adoption of Aspire.

Will it be possible for extensions to contribute tasks to the CD pipeline yaml?

Is the plan for Azure Pipelines support going to be in the form of a DSL for azure-pipelines? similar tohttps://github.com/sharpliner/sharpliner, or will there be a way to locally run and debug the pipeline? (or in phases, first a DSL, then debug+run capabilities)

Thanks for the roadmap, I know I've been waiting for the ability to debug into docker containers for a while so it's good to see that on the roadmap.
I'm curious how the Multi-Repo Support is going to play out. I currently have one large project with 10ish frontends/apis and Aspire has made it way easier to run the whole environment. I've now inherited some node projects in separate repos and have wanted to "glue" it all together as some of them call into the dotnet apis and services.

Container Sidecar Support - add native support / extension similar to WithDaprSidecar() taking as input a Dockized Sidecar Container, something like .AddSidecarContainer()

Container Replica Count Support - add native support / extension to .AddContainer() to allow a replica count to be set per container. This would also facilitate more advanced scenarios such as Chaos Testing.

Chaos Testing Support - add support for native Chaos Testing in .NET Aspire so that as a developer I can see how my distributed Aspire solution behaves. This would be a massive win for developers. Consider frameworks such asPumba etc.

Love the partial appHost axecution and running only subsets of the apps to make feedback faster and cleaner to review.

I see that Kubernetes is mentioned as being In-Progress as a Deployment Target. What will go into that? Automatic generation of Kustomize/Helm charts, or actual full deployment to a cluster from start to finish? What about other Kubernetes resources like Ingresses, etc? How about the estimated timeline for this?

I'm asking because currently I'm working on integrating Aspire into our production DevOps pipeline by making use of Aspir8. The issue is that it's not exactly being maintained and if something critical changes in Aspire, the whole tool might stop functioning, effectively breaking the pipeline.

If getting complete support of Kubernetes deployment including the most popular additional resources is possible, that would be amazing. Of course, 100% automatic deployment is probably not possible, but the less need to manually fix yaml files, the better.

Run Subsets of the App – Start only the services you need for faster feedback loops.

Does this mean also the option to notbuild those applications? Because that's where a lot of the slowing down of feedback loops is in.

I really love this doc! Makes a lot of things clearer.

I love aspire - I was able in2 hours to wire up 5 services, a GCP bucket emulator, postgres and more with VertexAI integration, but I am spending 2 more DAYs on figuring out the Auth and connecting it to Yarp.
If there was an out of the box OAuth2.0 integration with an AddRole, AddUser with roles and custom attributes, that would solve probably 90% of local dev experiences, and probably not too difficult to maintain.
Having then the Yarp integration connect to that authentication flow, means that I can run many production flows locally without a lot of fuss.

I wish the aspire dashboard be production-ready and an alternative to Grafana or other backend.

Would love an easier workflow with EF Core migrations as well.

Becausethis Microsoft Learn documentation page is quite a pain, especially when you have multiple services.

Run Subsets of the App – Start only the services you need for faster feedback loops.

How do I get involved in contributing on this feature? Are there already discussion documents around it?

Plugin model for the dashboard? So that the community can add more "tabs" to the left menu via extensions.

Most wanted item is:

• Debug .NET Projects Inside Containers – Run a .NET project in a container with support for interactive debugging from your IDE.

Local DNS names and proxying is going to be huge for me. Working with CORS and same origin locally is so important. Especially for multi tenant stuff.

Being able to assign multiple names, or create aliases for DNS names will be crucial.

Great stuff!