Replies: 3 comments 5 replies
-
Another thought here is that it should be possible to get a list of the environment variables being created and sent to the |
Beta Was this translation helpful? Give feedback.
-
I don’t understand the scenario here at all. Aspire doesn’t build containers or run your projects in containers. Running tests from the orchestrator isn’t a scenario that has come up. Testing orchestrated code is something that we’re going to provide but the end goal there is to be able to test your application and its dependencies |
Beta Was this translation helpful? Give feedback.
-
One problem solved: My assumption after running an Aspire host and then looking at the environment variables that are modified was that Service Discovery was using those to pass service mappings around. That's only partially true, though. Service Discovery didn't work is because So, I think this means Aspire services require the orchestrated child app to add This seems like an invalid (exceptional) state to me. It's not a typed contract, but it's a contract. I think perhaps that if That could apply to any orchestrator/orchestrated contract. (e.g. RedisServiceEndPointResolver) |
Beta Was this translation helpful? Give feedback.
-
I'm trying to find the best way to add a test project (or DLL or EXE) to be run from an Aspire AppHost. When using Visual Studio and debugging with F5, Visual Studio should also attach to the tests (and test project).
If I were using xUnit v3 (which has an EXE entry point instead of dll), I think I could just use
.AddProject("ExampleXunit3TestProject.csproj")
. As far as I know, any environment variables defined by.WithReference()
would remain intact while the tests are running. I don't know that for sure, though, since xUnit v3 generates aMain()
that, in turn, creates anXunitConsoleRunner
. That sounds like a new process to me (and therefore not attached to debugger), but still investigating. The author stated thatVSTestRunner
isn't available yet, which is the one that I think would attach the debugger to the new processes. @bradwilsonUsing xUnit v2, you have to use a test runner since there's no EXE to call. xUnit has their own test runners (e.g.
xunit.runner.console
), but it'd be preferrable to use a test framework agnostic test runner, which meansvstest.exe
, ordotnet test
or similar. In my initial testing, I lose my environment variables withdotnet test
, which means the tests don't have access to the modifications to environment from.WithReference()
. In other words, using.AddExecutable()
withdotnet test
results in tests not having access to.WithReference()
.In both of the above, it's unclear to me if VisualStudio would attach to the processes being spawned. I guess that's up to how
.AddExecutable()
is implemented. If it doesn't today, then it'd be great to do so or else add an option to do so.Ideally, it'd be great to add a new
DistributedApplicationBuilder
extension.AddDotNetCliCommand()
or.AddTestProject()
specifically to add test projects with the outcome of running them withdotnet test
.I think this also paves the way to being able to run tests from Visual Studio (or Resharper) UI into a docker container. To my knowledge, this is either not possible today, or not documented. This is assuming Aspire is going to allow F5 to put projects into a container instead of in process (through a launchProfile, perhaps?), and that it'll automatically attach to the process in the container. That or else use the trick that VisualStudio does with docker files where it mounts the EXE as a volume and just attaches to it locally.
Beta Was this translation helpful? Give feedback.
All reactions