You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[ test project ]
│
├──▶ client X ── uses Package Z v1 to call server Y
│
└──▶ server Y ── uses Package Z v2 for internal purposes (v1 ≠ v2, binary-incompatible and not upgradable for client X)
When the test project used WebApplicationFactory<Program> (in-memory server reference), the server DLL was loaded into the same CLR as the client. At run-time, the two different versions of Package Z collided and threw an exception.
My workaround was to spin up server Y in a Docker Testcontainer and talk to it over HTTP, e.g.:
an extra Dockerfile, whose image is rebuilt on every test run (and never cleaned)
additional start-up
the worst part: it's super hard to debug the server (adding a breakpoint in the server's code and then attaching it to the running Docker container, "catching" it while it runs).
I’d like to switch to Aspire using its dev-time orchestration and test helpers.
Questions
Process isolation - Does Aspire always run each AddProject(...) resource in its own OS/CLR process, so that the client with Z v1 can never accidentally load the server’s Z v2 assembly? (both in a standalone run, i.e., F5, and in the testing infrastructure Aspire provides)
Build-time package clashes - The default generic overload AddProject<TProject>() adds a normal <ProjectReference> to the AppHost so that it can generate Projects.* metadata. That means NuGet restores all transitive packages from both projects into a single build/assembly.
If Z v1 and Z v2 are genuinely incompatible, will this show up as build-time or run-time error?
Is using the path-based overload (AddProject("server", "../Server/Server.csproj")) or setting some csproj parameter (like IsAspireProjectResource) will avoid those build-time clashes?
Will debugging work for both the client and the server?
Samples / guidance - Are there reference repos or docs that show Aspire testing or a standalone run in action with intentionally divergent package versions between resources? I'm mostly concerned about the build process, how many assemblies are produced during the build, and the execution process (for example, I've imagined that every executable csproj, e.g., a web server, runs in a separate Docker container, and if that's not the case, that in a separate process - how it works?).
Any pointers or best-practice tips would be greatly appreciated—thanks!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
I have a diamond dependency situation:
When the test project used
WebApplicationFactory<Program>
(in-memory server reference), the server DLL was loaded into the same CLR as the client. At run-time, the two different versions of Package Z collided and threw an exception.My workaround was to spin up server Y in a Docker Testcontainer and talk to it over HTTP, e.g.:
That works, but it introduces:
I’d like to switch to Aspire using its dev-time orchestration and test helpers.
Questions
AddProject(...)
resource in its own OS/CLR process, so that the client with Z v1 can never accidentally load the server’s Z v2 assembly? (both in a standalone run, i.e., F5, and in the testing infrastructure Aspire provides)AddProject<TProject>()
adds a normal<ProjectReference>
to the AppHost so that it can generateProjects.*
metadata. That means NuGet restores all transitive packages from both projects into a single build/assembly.AddProject("server", "../Server/Server.csproj")
) or setting somecsproj
parameter (likeIsAspireProjectResource
) will avoid those build-time clashes?Any pointers or best-practice tips would be greatly appreciated—thanks!
Beta Was this translation helpful? Give feedback.
All reactions