c++ boost tests in vs2015 not working

I have a set of boost tests. They compile and run fine when started either from command line or from the run/debug buttons of visual studio. I am also able to see all my tests in my test explorer.

When I run them through the Resharper Unit Test Session (or Unit Test Explorer) they don't run and the only output I can see is: Child process exited with exit code "DLL not found"

I know what you're thinking... I'm missing a DLL. :-)   Yes, but the problem is that I don't know in what environment and with what command those files are executed and therefore I am unable to even tell which DLL might be missing. 

Is there a way to specify command parameters, environment variables and so on to make sure that all is run as it should ? Clearly it's not picking up all the parameters that I have in the projects' debugging configuration.

For the record, I'm running Visual Studio 2015, with boost 1.62.0 with Resharper c++ 2016.3.1

Any suggestions?

Comment actions Permalink

Hello Daniele,

The test runner uses "Command", "Command Arguments", "Working directory" and "Environment" properties from the "Debugging" property page of the project which contains the tests. Visual Studio uses the same properties when running/debugging binaries, so if there's a DLL missing, you should have got the "DLL is missing" error when running the tests via VS too.

Could you please check if your tests are located in the test binary project? What are these properties set to for this project? Could you reproduce this issue on a solution which you could share so we could take a look?

We've also seen a rare problem when Visual Studio does not correctly report the evaluated project property. If you get the missing DLL error, it might be a symptom of incorrect "Environment" property (because environment paths are used when resolving DLLs). You could check if this is the case by setting the "Environment" property to its evaluated value - please see https://youtrack.jetbrains.com/issue/RSCPP-14889#comment=27-1435343 for a similar problem which occurred with the Intel MKL library.


Comment actions Permalink

You are absolutely right ! 

My problem indeed had to do with the Intel MKL library, and writing out the full PATH made things work. 

I also originally thought that it wasn't using the other "Environment" properties either, but clearly it does. 

So I'm all set, everything works, and it's amazing that you also thought of pointing out that issue with the MKL library.

Thanks for the support, I'm very impressed. 


Comment actions Permalink

Thanks! Sorry about the issue, I couldn't figure how to work around it - will take another look.


Please sign in to leave a comment.