This was not an easy one… I was trying to run a unit test with MSTest but I was always getting the following error:
Unit Test Adapter threw exception: Type is not resolved for member ‘XXX,XXX Version=22.214.171.124, Culture=neutral, PublicKeyToken=null’
As usual in such case – a message which does not really say what’s wrong. I googled the problem but there was not much about it on the web. The best resource I found was post titled VSTS Unit Test ‘Type is not resolved’ exception. It describes how VSTestHost process runs the test and explains what the possible problem might be in this case.
The author suggests that data required for test (e.g. a dll file) is not found in base directory for AppDomain (i.e. unit test ‘Out’ directory) because it’s already switched back to directory that holds VSTestHost.exe. There are two links to MSDN given where Microsoft admits this is a known bug and provides a hack to work around the problem – supply VSTestHost with copies of required artifacts (again, this is described in details in above mentioned post).
Unfortunately that didn’t work with my case. I’ve found the root cause though…
Now, to be more precise, that error message was telling me the member whose type was unresolved was a class with implementation of my custom exception. For the sake of the example let’s assume that the message I was getting looked as below:
Unit Test Adapter threw exception: Type is not resolved for member ‘MyCustomException,TestProject, Version=126.96.36.199, Culture=neutral, PublicKeyToken=null’,
where TestProject is the project in which I wrote MyCustomException class.
This information implied something wrong was happening at the the very beginning of the test – exception might be thrown between class initialization (MSTest ClassInitialize) and class constructor or fields’ definition. I analyzed, line by line, the earliest logic looking for an invocation that could throw MyCustomException, and I found it… MyCustomException was thrown at the definition of one of the class fields. With that fixed, the test was running without problems.
To recap, MyCustomException was thrown at very early stage of test execution. The dll that contained it was not loaded yet so Unit Test Adapter indeed could not reach it. The general idea provided in the referred post really matched my problem. However, in details the root cause in my case was slightly different.