MSTest: Unit Test Adapter threw exception: Type is not resolved for member XXX

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=1.0.0.0, 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…

Solution

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=1.0.0.0, 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.

3 Responses to “MSTest: Unit Test Adapter threw exception: Type is not resolved for member XXX”


  • not getting solution for following

    Server Error in ‘/’ Application.
    ——————————————————————————–

    Type is not resolved for member ‘CHD.G2G.Business.Security.CustomIdentity,CHD.G2G.Business, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.
    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.Runtime.Serialization.SerializationException: Type is not resolved for member ‘CHD.G2G.Business.Security.CustomIdentity,CHD.G2G.Business, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [SerializationException: Type is not resolved for member 'CHD.G2G.Business.Security.CustomIdentity,CHD.G2G.Business, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.]
    Microsoft.VisualStudio.WebHost.Server.GetProcessToken() +0
    Microsoft.VisualStudio.WebHost.Host.GetProcessToken() +80
    Microsoft.VisualStudio.WebHost.Request.GetUserToken() +27
    System.Web.HttpContext.get_ClientIdentityToken() +31
    System.Web.HttpContext.get_ImpersonationToken() +107
    System.Web.ClientImpersonationContext.Start(HttpContext context, Boolean throwOnError) +103
    System.Web.ClientImpersonationContext..ctor(HttpContext context) +38
    System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert) +150
    System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +56
    System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath) +112
    System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig) +352
    System.Web.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +182
    System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +191

    ——————————————————————————–
    Version Information: Microsoft .NET Framework Version:2.0.50727.1891; ASP.NET Version:2.0.50727.1887

  • Sharmila,

    What the error says is when executing the code one of the type is not accessible at runtime. It’s hard to guess what’s wrong without looking at the code, but what I’d suggest is to look at the definition of that type / member and check whether it’s posible to make it more visible. For instance, that class / member is marked private because it looks like it’s used only in one particular scope (class) but at runtime code execution is delegated to the other class (e.g. derived class) for which the code is inaccessible.

    I hope this makes sense,
    Jarek

  • Thanks Jarek, this post gave me a quick hint on where to look for the source of the problem. In my case, custom exception was thrown from the test class constructor. Which goes to show that initializing test classes in constructors is not such a good idea, they should rather be initialized in [ClassInitialize] method.

Leave a Reply