参考用于CI构建的Microsoft.VisualStudio.QualityTools.UnitTestFramework

jam*_*iet 26 c# unit-testing visual-studio vs-2015-preview

我在VS2015 RC中创建了一个C#测试项目.它在本地构建,但是当我尝试构建我们的CI构建服务器(TeamCity)时,它会失败并出现错误:

UnitTest1.cs(2,17):错误CS0234:命名空间"Microsoft"中不存在类型或命名空间名称"VisualStudio"(您是否缺少程序集引用?)[D:\ BuildAgent\work\e486bf18e454d0c2\dh. PSP.Coordinator.Api.Tests\dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs(9,10):错误CS0246:找不到类型或命名空间名称'TestMethod'(你是否错过使用指令或程序集引用?)[D:\ BuildAgent\work\e486bf18e454d0c2\dh.PSP.Coordinator.Api.Tests\dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs(9,10):错误CS0246 :找不到类型或命名空间名称'TestMethodAttribute'(您是否缺少using指令或程序集引用?)[D:\ BuildAgent\work\e486bf18e454d0c2\dh.PSP.Coordinator.Api.Tests\dh.PSP. MetadataService.Api.Tests.csproj] UnitTest1.cs(6,6):错误CS0246:找不到类型或命名空间名称'TestClass'(您是否缺少using指令或程序集引用?)[D:\ BuildAgent \工作\ e486bf18e454d0c2\dh.PSP.Co ordinator.Api.Tests\dh.PSP.MetadataService.Api.Tests.csproj] UnitTest1.cs(6,6):错误CS0246:找不到类型或命名空间名称'TestClassAttribute'(您是否缺少using指令或程序集引用?)[D:\ BuildAgent\work\e486bf18e454d0c2\dh.PSP.Coordinator.Api.Tests\dh.PSP.MetadataService.Api.Tests.csproj]

显然这是因为包含这些命名空间的程序集(Microsoft.VisualStudio.QualityTools.UnitTestFramework)不在构建服务器上,在我的本地计算机上它位于C:\ Program Files(x86)\ Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.我想我可以将程序集复制到我的解决方案中,以便它成为代码库的一部分,但手动移动文件感觉就像是一个不优雅的黑客.我在nuget周围搜索并找到了http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/,我认为这样可以解决问题,但安装该软件包失败了:

安装包:无法安装包'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'.您正在尝试将此软件包安装到以".NETFramework,Version = v4.5.2"为目标的项目中,但该软件包不包含任何与该框架兼容的程序集引用或内容文件

解决这个问题的最佳选择是什么?我很惊讶在VS2015中创建一个测试项目并没有自动包含我需要的所有依赖项,尽管我可能是天真的(我是一个刚刚起步的点网).

MiF*_*vil 6

答案类似于eng.augusto's answer 中的选项 1 。
Microsoft 不为最新版本提供 NuGet,Microsoft.VisualStudio.QualityTools.UnitTestFramework, 而是将其作为 Visual Studio 的一部分提供(通常在 C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

我将该文件夹创建Microsoft.VisualStudio.QualityTools为解决方案的子文件夹并复制:

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

这些文件应该添加到源代码管理中(即使 DLL 通常被忽略)。
然后我更改了 Test.csproj 中的引用以引用新位置。


小智 5

嗯,我有一些想法,所以选择最适合您需求的一个

  1. 一个简单的答案应该是将 DLL 标记为复制到本地,并在解决方案的同一文件夹中使用像 Assemblies 这样的文件夹,并引用“Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll”
  2. 在构建服务器中安装 Visual Studio。听起来很疯狂,但它是您拥有的最接近“开发人员机器”的。
  3. 将 DLL安装在 GAC 中,这样您就不必为此烦恼。
  4. 修复 NuGet 包(添加 .NET Framework 版本的引用)并使用它。
  5. 降级 .NET Framework 版本,以便可以使用 NuGet 包。
  6. 创建您自己的 NuGet 服务器!(并添加您需要的 DLL 的引用)。

恕我直言,我会选择第一个答案,因为它似乎是使用 NuGet 解决所有包问题的“最佳方法”,但您使用的 DLL 不知道它是否值得信任。

在使用 C 或 C++ 等“旧”语言的系统中,您通常会下载源代码和代码运行所需的库,因此我认为 NuGet 包不是最好的解决方案。

使用第一个选项,您始终拥有相同的版本,并且可以检查文件的 MD5 并准确了解构建服务器中正在运行的内容。

也许真正最好的选择应该是 6。当您使用自己的 NuGet 服务器来处理 DLL 时,使您的生活更加精彩和值得信赖。

  • 或者你可以通过使用 xunit、nunit...任何不是来自微软的东西来避免所有这些恐怖。 (6认同)