-
Hi everyone, I have a diamond dependency situation:
When the test project used My workaround was to spin up server Y in a Docker Testcontainer and talk to it over HTTP, e.g.: // simplified
await new ContainerBuilder()
.WithImage(_serverDockerImage)
.WithPortBinding(8080, true)
.WithWaitStrategy(Wait.ForUnixContainer()
.UntilHttpRequestIsSucceeded(r => r.ForPath("/health")))
.Build()
.StartAsync(); That works, but it introduces:
I’d like to switch to Aspire using its dev-time orchestration and test helpers. Questions
Any pointers or best-practice tips would be greatly appreciated—thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Update: I've tried it, and it worked like a charm. However, worth noting that having I've added an AppHost project with Aspire.AppHost.Sdk. In it, I added a The tests project has a All works well. The tests project uses version v1 of package Z, while the server referenced by the AppHost uses v2 of package Z. While v1 is incompatible with v2, the diamond dependency is avoided. So, all good. Worth noting that on paper, it still seems like there's a diamond dependency problem. Since Aspire uses These "references" are "weak references" that don't affect the binaries or the runtime in that sense. They are just used for some source generation to create files with links to .csproj files, and while the documentation explains that, it's still very misleading. I think a different approach would work better, like adding a flag or a special keyword for these references, like |
Beta Was this translation helpful? Give feedback.
Update: I've tried it, and it worked like a charm. However, worth noting that having
ProjectReference
is confusing in this case.I've added an AppHost project with Aspire.AppHost.Sdk. In it, I added a
ProjectReference
to a migration service and to the server. Additional references: "Aspire.Hosting.AppHost" and "Aspire.Hosting.PostgreSQL". These references created the relevant code for.AddProject<>
, basically a class with a "ProjectPath" string.The tests project has a
ProjectReference
to that AppHost, which allows usingDistributedApplicationTestingBuilder.CreateAsync<>
.All works well. The tests project uses version v1 of package Z, while the server referenced by the AppHost uses v2 of …