在x64 C ++ / CLI上的MSTest

Question

I got a problem using MSTest on x64: The test project depends on a couple of C++/CLI assemblies, and fails to load for some reason. In Visual Studio, I get (stripped down):

Error loading D:\\xxx\\Xxx.Test.dll: Unable to load the test container 'D:\\xxx\\Xxx.Test.dll' or one of its dependencies. Error details: System.BadImageFormatException: Could not load file or assembly 'Common.Geometry.Native, Version=1.1.4574.22395, Culture=neutral, PublicKeyToken=null' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Running MSTest manually in a command prompt, I get:

Unable to load the test container 'D:\\xxx\\Xxx.Test.dll' or one of its dependencies. Error details: System.IO.FileNotFoundException: Could not load file or assembly 'Common.Geometry.Native, Version=1.1.4574.22395, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

Details worth mentioning:

• The test project itself is compiled using 'Any Cpu'.
• I use a x64 specific testrunconfig
• Dependency walker shows no missing native dependencies in the C++/CLI assembly (Common.Geometry.Native)
• Even more interesting, there is another test project in the same solution using the same C++/CLI assembly (Common.Geometry.Native), and it runs without any problems.

I have also verified that there are no 32bit assemblies/dlls interfering.

Any suggestions is welcome !

Answer 1

I'd initially thought that microsoft didn't add a 64-bit capable test runner for MSTest until 2012... As it turns out, VS2010 is capable of this.

What I'd check then is if your native dll has any other native dependencies.

MSTest has a "mis-feature" where, before running your tests, it creates a temp directory, usually something like PC-NAME WORKSPACE_NAME 1782368124\\Out , and it copies your code into that directory. For .NET assemblies, it can figure out the dependencies and is able to copy them, but for native code it does not appear to do this.

I've solved this in the past by adding the directory containing any other native dependencies to the PATH environment variable for my user account (remember if you do this to restart visual studio as it won't notice)