Could not load file or assembly 'Microsoft.VisualStudio.TestPlatform.ObjectModel, Version=11.0.0.0'

Question

I am using MSTest.TestAdapter and MSTest.TestFramework both version 1.2.0 for my MS tests unit tests. On my local machine (Visual Studio 2017) the tests run perfectly, but on our build server we get this message:

Could not load file or assembly 'Microsoft.VisualStudio.TestPlatform.ObjectModel, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Then I checked the reference of this assembly with ildasm, and indeed it is the 11.0.0.0 version (see below)

However I cannot find the v11 of this assembly, online there is only the v14 version on nuget: https://www.nuget.org/packages/Microsoft.VisualStudio.TestPlatform.ObjectModel/

I also searched on my machine and I couldn't find the v11.

So my question, why does the tests run on my machine and not on the build server?

I tried assembly binding but without success.

Answer 1

The NuGet package you want is Microsoft.TestPlatform.ObjectModel authored by Microsoft, not the Microsoft.VisualStudio.TestPlatform.ObjectModel package authored by Christopher.Haws.

https://www.nuget.org/packages/microsoft.testplatform.objectmodel/

The Microsoft package has Microsoft.VisualStudio.TestPlatform.ObjectModel assemblies in it, despite it not being named that way. I was getting the same error and when I installed v11 of the Microsoft package it fixed the build on the build server for me.

Answer 2

Same issue, I was able to install the latest version:

Install-Package Microsoft.TestPlatform.ObjectModel -Version 15.8.0

Then add a binding redirect to the test projects app.config:

    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.VisualStudio.TestPlatform.ObjectModel" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
                <bindingRedirect oldVersion="11.0.0.0-14.0.0.0" newVersion="15.0.0.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>

Answer 3

Other workarounds are recommended here

Don't reflect types from "Microsoft.VisualStudio.TestPlatform.ObjectModel" assembly. OR Downgrading Microsoft.NET.Test.Sdk to 15.3.0.

Probably the second option does not apply for you since you are on .NET framework and not .NET core.

More background:

• https://github.com/nunit/nunit3-vs-adapter/issues/388
• https://github.com/microsoft/vstest/issues/1098

Answer 4

In the test output window I had errors like this…

[MSTest][Discovery][C:\Repos\Flomaster\bin\Debug\ApiTest.UnitMaintenance.dll] Failed to discover tests from assembly C:\Repos\Flomaster\bin\Debug\ApiTest.UnitMaintenance.dll. Reason:Type 'Microsoft.VisualStudio.TestPlatform.ObjectModel.Trait' in Assembly 'Microsoft.VisualStudio.TestPlatform.ObjectModel, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

I managed to get my test runners working by Cleaning out all my obj and bin\debug folders, but it came back so I looked a bit deeper and found that just searching for Microsoft.VisualStudio.TestPlatform.ObjectModel.dll and removing any matching files was enough to get the test runner working

Answer 5

after facing the same issue again in another project, we looked at it again and found a solution.

Install-Package Microsoft.TestPlatform.ObjectModel -Version 11.0.0

But this was not enough, to make sure the assembly was picked up by the build server, we added it as a deployment item to the base test class;

[DeploymentItem("Microsoft.VisualStudio.TestPlatform.ObjectModel.dll")]

And now the build server is again picking up the unit tests :-)

Grtz

Answer 6

Faced the same error after having mistakenly added the NuGet package for NUnit 3.0 to several projects in the solution and then removing it.

The reference didn't get removed completely. I had to open each .csproj file manually and delete all references to the previously removed NuGet package. After a clean and rebuild, the error went away.