Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Location of Runnable EXE Not As Assumed #47

Open
allan-bommer opened this issue Aug 11, 2021 · 3 comments
Open

Location of Runnable EXE Not As Assumed #47

allan-bommer opened this issue Aug 11, 2021 · 3 comments

Comments

@allan-bommer
Copy link

I have been having trouble with discovery, but think I have diagnosed the problem.
The "output directory" (in vs proj file) contains the exe, but not in runnable form. Our build system symlinks it into another directory with all its dependencies for running/debugging. This is handled with a custom Debug Command.

So.. "MyTests.exe --list-tests" will crash instead of returning anything useful.

Is there a way to control where the discoverer looks for the exe to discover the tests?

@JohnnyHendriks
Copy link
Owner

The path to the executable is provided by Visual Studio, the test adapter has no control over this. That said, I would expect a symlink to just work, but I'm not very familiar with symlinks so I'm not sure. I assume you can run the test executable on the commandline using that symlink.

@allan-bommer
Copy link
Author

Thanks for the quick reply. I didn't explain the symlink issue clearly enough. The output directory contains the real (not symlinked) EXE, but none of the required DLLs. Both the EXE and those required DLLs are symlinked into another directory for testing purposes....so we need to run the EXE from that other directory, not the output directory.

Our team ran into the same issue with NUnit. We were able to resolve that one (using AssemblyResolver)...but I don't think that solution will work for C++. We may do a little digging into the adapter source to see if there are any likely opportunities.

Thanks again.

@JohnnyHendriks
Copy link
Owner

In the last release of the Test Adapter I added support for setting Environmental variables. Maybe setting a PATH variable with the location of the dlls may help your situation. If you will be looking into the test adapter code, then you probably need to look here and here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants