Reference Microsoft.VisualStudio.QualityTools.UnitTestFramework for CI build

Question

I have created a C# test project in VS2015 RC. it builds locally but when i attempt to build on our CI build server (TeamCity) it fails with errors:

U

Answer 1

I was having this issue when trying to use MSBuild on our dev server via our CI/CD process after I was asked to uninstall VS2013 from our dev server by our IT team.

In my case in my build output there were a few lines with the word Considered. What this means is that the build is considering those folders for locations where the file may be located. One of those lines was as follows:

Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.

I copied Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from my local machine to that folder on the dev server and the error went away.

Answer 2

For projects created in VS 2017. Adding Nuget package Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated allows to build unit test projects on CI without VS installed on build server:

Answer 3

Of course Microsoft does a s...t job. To fix this, you need to copy the dll's to some convinint lication and reference them from your ptoject .csproj file.

    <HintPath>..\packages\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
    </Reference>
  </ItemGroup>
  <ItemGroup>
      <Reference Include="QualityTools-Fakes">
        <HintPath>..\packages\Microsoft.QualityTools.Testing.Fakes.dll</HintPath>
      </Reference>
    </ItemGroup>
  <ItemGroup>

I don't understand why when we add this from VSudio it does not update the same file instead no one has an idea what it does. In Java you have a single file pom.xml or build.gradle, nothing else. In C# there is all sorts of stuff which adds no value but confusion.

Answer 4

Hmm I have some ideas, so choose the one that best fits your needs

1. A simple answer should be mark the DLL to copy local and use a folder like Assemblies in the same folder of the solution and references "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
2. Install Visual Studio in your build server. Sounds nuts but it's the closest to "developer machine" that you have.
3. Install the DLL in the GAC so you don't have to bother with this.
4. Fix the NuGet package (Adding a reference for the .NET Framework version) and use it.
5. Downgrade your .NET Framework version so you can use the NuGet package.
6. Create your own NuGet server! (and add the reference of the DLLs you need).

IMHO I'd choose the first answer, because it seems to be the "best way" to use NuGet to resolve all your packages problems but you are using a DLL that you don't know if it should be trusted.

In system used in "old" languages like C, or C++ it's common you download the source code and the libraries needed for the code to run so I do not think the NuGet package it's the best solution.

Using the first option you always have the same version and could check the MD5 of the file and know exactly what is running in your build server.

Maybe the real best option should be 6. When you use your own NuGet server to handle your DLLs making your live more awesome and trustable.

Answer 5

The answer is similar to option 1 in eng.augusto's answer.
Microsoft doesn't provide NuGet for the latest version of Microsoft.VisualStudio.QualityTools.UnitTestFramework, but rather supplies it as a part of Visual Studio (normally at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)

I created the folder Microsoft.VisualStudio.QualityTools as a subfolder of my solution and copied:

Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml

The files should be added to source control (even if DLLs are usually ignored).
Then I changed references in my Test.csproj to refer to a new location.