Mstest单元测试从命令行失败

Question

I have written a unit test that uses the testsettings file to deploy some referenced dll in the OUT folder. I run my unit test using this command.

"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\MSTest.exe" 
"/testcontainer:C:\Unittests\unit_test.dll" 
"/runconfig:C:\Unittests\unit_test_settings.testsettings" 
"/resultsfile:C:\Unittests\unit_test_results.trx"

Some tests in my unit test run fine but some fail with the following error.

Failed object initialization (ISupportInitialize.EndInit). The satellite assembly named "some_referenced_dll.resources.dll, PublicKeyToken=" for fallback culture "en" either could not be found or could not be loaded. This is generally a setup problem. Please consider reinstalling or repairing the application.
System.Resources.MissingSatelliteAssemblyException: The satellite assembly named...

In an attempt to fix this, I added the some_referenced_dll.resouce.dll as a deployment Item in the testsettings file but that didn't help.

I can see that the dlls are getting copied in the OUT folder.

Also the tests are running fine from VS 2012 after I add the some_referenced_dll.dll as a reference to the project.

MORE INFO:

There are tests that are using some other dll as refrence directly (say ref_dll_2.dll) and passing. This ref_dll_2.dll is also in the OUT folder.

I am facing the problem with a dll (some_referenced_dll.resouce.dll) that is not directly referenced from my test. My unit test calls into some dev code which inturn tries to initializes a class which fails.

Would be make sense to forcefully load a dll? Is there a way to do that?

Answer 1

OK so I finally fixed the problem. Documenting here for completeness.

The problem was that my MSTEST unit test could not find the resource/satellite assembly (some_referenced_dll.resources.dll) and was thus throwing the exception. I was using the deploymentItem attribute to deploy the dll (some_referenced_dll.dll) but not the resource dll. The solution was to use the deploymentItem and deploy the resource dll (some_referenced_dll.resources.dll) as well.

Bill Wang provided an excellent answer in this thread that helped solve the problem. It was a simple fix for a really irritating problem.