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:

UnitTest1.cs(2,17): error CS0234: The type or namespace name 'VisualStudio' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) [... .Tests.csproj] UnitTest1.cs(9,10): error CS0246: The type or namespace name 'TestMethod' could not be found (are you missing a using directive or an assembly reference?) [... .Tests.csproj]

Clearly this is because the assembly containing these namespaces (Microsoft.VisualStudio.QualityTools.UnitTestFramework) is not on the build server; on my local machine it resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.

I could copy the assembly into my solution so that it becomes part of the codebase but manually moving files feels like a bit of an inelegant hack. I searched around on nuget and found http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ which I figured would do the trick, but installing that package failed with:

Install-Package : Could not install package 'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'. You are trying to install this package into a project that targets '.NETFramework, Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework

What's my best option of solving this? I'm surprised that creating a test project in VS2015 does not automatically include all the dependencies that I need, though perhaps I'm being naive (I'm something of a fledgling dot netter).

Answer 1

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.

Answer 2

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.