Aspire 9.0 - Different networking behaviour for Run and DistributedApplicationTestingBuilder

[ggmueller]

I think there is a slight different behavior when running an Aspire workload vs using DistributedApplicationTestingBuilder concerning Docker networking.

Aspire Version: 9.0
Container Runtime: Docker

When running the Aspire AppHost (via dotnet run) a new bridge network is created (default-aspire-network-...). When running via DistributedApplicationTestingBuilder I can see no custom bridge network. Instead, the containers are attached to the default network.

Then, as far as I understand, in Docker these networks behave slightly differently. With the custom bridge network, the containers can be discovered via DNS aliases on the network. On the default network, they do not seem to be discoverable via DNS.

In my case I have a dotnet service in a container, that references SqlServer in the container. As it uses the container alias to resolve the server, it can not reach it.

Is there some configuration on DistributedApplicationTestingBuilder to enable the custom bridge framework?

[davidfowl]

cc @danegsta

[danegsta]

I’ll take a look to figure out what’s happening; we should be automatically creating a bridge network if there are any container resources being created.

[danegsta]

@ggmueller I tried reproducing with our existing DistributedApplicationTestingBuilder tests but I'm seeing the expected Aspire bridge network created and used during the run. The existing code should always create the bridge network if there are any container resources defined in your app model.