dapr configuration is removed from aca when deploy stage of azd up is run

[garrardkitchen]

• Make sure you've installed the latest version using instructions

Output from azd version
azd version 1.22.0

Describe the bug
If you use terraform instead of bicep and configure your aspire apps (container apps) to use dapr sidecar, the terraform deploys the dapr config correctly but when the apps then get deployed, it disables/removes the dapr configuration

To Reproduce
azd up -e

Expected behavior
Not to remove the aca dapr configuration.

Environment
Information on your environment:
* .NET 10
* macOS
* IDE and version : n/a

Additional context
Add any other context about the problem here.

[garrardkitchen]

Code snippets

var acaEnv = builder
    .AddAzureContainerAppEnvironment("dev")
    .WithDaprSidecar()
    .WithDashboard();

var apiService = builder.AddProject<Projects.dapr_test_ApiService>("apiservice")
    .WithHttpHealthCheck("/health")
    .WaitFor(serviceBus)
    .WithReference(serviceBus)
    .WithReference(topic);

// tried with and without this:
if (builder.ExecutionContext.IsRunMode)
{
    apiService.WithDaprSidecar(sidecar => sidecar.WithReference(pubsub2));
}

To prove I'm using terraform with azd:

name: dapr-test
services:  
  app:
    language: dotnet
    project: ./dapr-test.AppHost/dapr-test.AppHost.csproj
    host: containerapp
infra:
  provider: terraform
  path: infra

[garrardkitchen]

Wow, this is now the case with bicep 😢

[vhvb1989]

Hi @garrardkitchen , Terraform+Aspire is not supported.

When you use infrastructure as code with azd (like bicep or terraform from infra folder), it would override anything defined by the Aspire AppHost.
You can generate IaC from Aspire AppHost running azd infra gen. This translates the AppHost into bicep.

I think this builder.ExecutionContext.IsRunMode is always false for deploying. Right @captainsafia ?

[garrardkitchen]

Hi @vhvb1989 , Thank you for your guidance.

This is what I've found works. Also, every time I add a new service, I execute another azd infra gen and roll back any incorrect changes - normally dapr related!

The only way I've found to work with dapr, aspire, and azd is to manage the infra outside of aspire.

I've found there's not much love towards dapr in the aspire discord - I have received advice to refactor out my dependency on dapr. I found this advice confusing as dapr is a first class capability of several azure services.

Lately, I've spent a considerable amount of my time working with aspire, azd, TF, and Azure as part of my day job.

This week, I saw the development and deployment of my first Vite app to production! I'll be dropping my apphost viteapp code into the aspire discord to get feedback. Run mode and deploy requires slightly different code - for deployment, I'm using docker.

I can confirm
'builder.ExecutionContext.IsRunMode' is always false for deploying.

Thanks!

G.

[vhvb1989]

@garrardkitchen , what I can see about dapr is that it was moved to the community tool kit

https://www.nuget.org/packages/CommunityToolkit.Aspire.Hosting.Dapr/

This means that dapr is now an optional add‑ons built by the community. I think it was initially part of Aspire directly, but it was moved at some point. That could explain why you don't see the same love in discord for it as you see for other things.

You might have some lucky by directing your dapr question to @aaronpowell or @FullStackChef , I think they have been maintaining the dapr stuff

[garrardkitchen]

Hi @vhvb1989 , yes, I am aware of this. I have been using aspire (and azd) for some considerable time. I have been a member of both (they moved) Discords and visit regularly.

Brett has work commitments...the rub of having integrations maintained by volunteers. I have not pinged Aaron.

I have a good grasp on the limits/reach of aspire and approaches to use with regards to dapr.

I remain surprised dapr being a first-class capability in several Azure (Microsoft) services, and it is not considered as such within aspire. Shame.

G.

[FullStackChef]

I wouldn't consider dapr a first class capability in azure - the versioning in azure is well behind the current dapr version.

AZ will attempt to deploy based on items being part of the generated manifest - if you're looking to use dapr locally without the deployment side I would suggest looking at ExcludeFromManifest method in aspire (I assume it still exists)

[garrardkitchen]

Hi @FullStackChef , I never said all of Azure, only in several services (ACA, AKS, AzFuncs).

We are using it both locally, and in production.

G