Aspire CLI: deploy feedback and suggestions

[mip1983]

I'd not really planned on a journey into the Aspire CLI just yet, as I thought I'd wait for some of the key bits I need like 'deploy' to lose their preview label, but I've hit on a hard limit with azd where my solution results in a 'main.bicep' with more than 64 outputs, and there doesn't seem to be a way forward. Given urgency to be able to release, aspire cli deploy seemed to work with no such limit, so that's the way I went. I thought based on the experience I'd give some feedback.

Docs suggestions:

1. On the Overview page, maybe under the intro paragraph there could be a bullet point one line summary of each command? You do have the one line description on the page for each command e.g. on aspire do you have 'Execute a specific pipeline step and its dependencies.'. I'm thinking it would be quite handy on overview to have all these one line summaries in one place so you don't need to click through each. (I didn't realize I could deploy individual projects until David Fowler pointed out what 'do' did in discord).
2. Some of the documented stuff doesn't seem to be there when you try it, aspire doctor just results in 'unrecognized command for me' having only just installed the cli (13.1).

Deploy functionality:

Confusing with parameters and how to supply them in a build pipeline. Initially the docs said you can use a parameters file or pass parameters in the command line. That's turned out to be outdated so has been changed now.

I've ultimately taken the concept and rolled it myself. I've gone from scripting the different steps in yaml to minimizing the amount of yaml and getting it to 'dotnet run' a single C# file as a deploy script. I've still got different parameters.json files (for each deploy environment), and in there I've got non-secret values and placeholders for secrets (which I substitute from a library in the build pipeline). Then the C# script just takes these files, translates the contents into environment variables (e.g. 'Connectionstrings__connection' or 'Parameters__My_Param'), installs the aspire cli, then runs relevant aspire commands (e.g. aspire do deploy-myproject) based on things passed in (via env) depending on what you tick when you run the pipeline. Maybe a bit convoluted, but there's something I find easier with a json file. There's ultimately a lot of variables in our application, lots of API's we integrate with etc. so a file per environment with secrets tucked away elsewhere seems more manageable than trying to pass a big flat list in a build pipeline.

Running on a Windows agent in Azure Pipelines

Initially I was trying to do all of this on a windows agent (azure managed pool), which I couldn't get to work and have now switched over to a linux agent.

It initially complained about docker, even though the windows agent has docker (and I put the docker install step). Debugging, it looked like it couldn't find a particular docker command 'buildx'. Co-pilot gave me an additional step to add this docker cli plugin, which seemed to resolve that. However, once resolving buildx, it still complained about not being able to build a linux container, which is the point I gave up and switched over to a linux agent (where I don't need the step to get buildx). I guess it all works on my local windows machine as I've got things like WSL?

I presume not everyone will have the option of choosing their agent OS or may have some windows dependency. Perhaps some work can be done with the Azure DevOps people to get their side aspire ready? i.e. their windows images could have WSL by default, and they could add an 'Install Aspire CLI' task, that apart from doing that, also adds 'buildx' to docker if it's a windows agent (or maybe that could be in the agent image by default as well).

Summary

Bit of an unexpected road trip into the aspire cli, quite a few hurdles, but now I'm there, its working quite nicely. I do quite like that I've chopped out lots of yaml and doing stuff via C# single file experience. I think it's long been a challenge figuring out how to get parameters and secrets into an aspire app in a build pipeline and troubleshooting that whether it was azd or now this, so any smoothing out/documenting of that is appreciated.

[vst121]

Thanks for sharing, I want to say:

• aspire do handling individual projects really helped you bypass the Bicep 64-output limit, which is a good example of why “per-project deploy” can be valuable. Creating your own C# deploy script with JSON parameter files and secret substitution is a clever way to simplify the YAML pipeline and manage environment-specific configs.
• Running Aspire on Windows Azure Pipelines can be tricky (missing buildx, WSL dependencies), so highlighting Linux agents as simpler is useful. Your suggestion about pre-baked Windows images with WSL and buildx installed—or an “Install Aspire CLI” pipeline task—is a solid idea to reduce friction.
• The CLI works well once you get past these pain points, and your suggestions for documentation and agent setup would make the onboarding and CI/CD experience much smoother for others.

[davidfowl]

@IEvangelist