使用团队城市构建时“无法加载文件或程序集”答案

【问题标题】："Could not load file or assembly" when building using team city使用团队城市构建时“无法加载文件或程序集”
【发布时间】：2014-02-05 12:41:42
【问题描述】：

我在 Team City (8.0.4) 构建服务器上遇到了单元测试问题 - 代码通过 Resharper 和 nCrunch 在本地构建和运行所有测试。

但是在服务器上运行时出现以下错误，即使 Unity 程序集与单元测试程序集存在于同一目录中，并且在单元测试程序集中被引用。

SetUp 方法失败。 SetUp：System.IO.FileNotFoundException：无法加载文件或程序集“Microsoft.Practices.Unity，版本=2.0.414.0，Culture=neutral，PublicKeyToken=31bf3856ad364e35”或其依赖项之一。该系统找不到指定的文件。在 XXXX.Unity.UnityContainerAdapter..ctor() 在 XXXX.GraphExtensionsTests..ctor() 在 c:\TeamCityV7\Agent-1\work\f02f7e27c0bedfa2\XXXX\Graph.Tests\Extensions\GraphExtensionsTests.cs:line 44

我已确认 Microsoft.Practices.Unity 的副本是正确的版本。

我还确认程序集是使用完整版框架构建的 - 不是使用客户端配置文件。

您知道 Team City 可能会失败的原因吗？

【问题讨论】：

您是否正在使用 NuGet 包进行 Unity？如果不是，我建议您这样做，因为我发现在使用 NuGet 时，很多这些参考问题变得更加直接。
如果可以的话，我会“愿意”，但受制于政治......
如果您想了解它在哪里寻找“缺失”程序集，您可以使用名为 fuslogvw 的 Windows 实用程序，described here。

标签： .net unit-testing continuous-integration teamcity .net-assembly

【解决方案1】：

检查您用来定位测试程序集的模式。我在另一个库中遇到了类似的问题，结果发现模式是在 bin\Release 和 obj\Release 下找到测试程序集； obj 文件夹不包含项目引用的所有程序集，实际上只是编译器的临时文件夹。

【讨论】：

宾果游戏！另一个测试程序集引用了一个恶意测试程序集，并且它也在运行恶意程序集测试。
不错，完成了工作！ :)
我能够通过将我的 测试文件名 模式从 **\*.Tests.dll 更改为 **\bin\**\*.Tests.dll 来解决此问题

【解决方案2】：

我最近发现的另一种可能性是，如果您正在使用未显式引用的库，TeamCity 将不会收集库以供使用，并且在隐式引用程序集时会失败。当我试图弄清楚为什么在我的测试项目中引用的 NHibernate.ByteCode.Castle 没有被加载并导致 TeamCity 上的 FileNotFoundException 时，我发现了这一点。最终，我做了一个像这样的“虚拟”单元测试：

using Microsoft.VisualStudio.TestTools.UnitTesting;
using NHibernate.ByteCode.Castle;

namespace MyNamespace
{
    [TestClass]
    public class CastleProxyPresenceTest
    {

        [TestMethod]
        [TestCategory("Infrastructure: This test forces TeamCity to load the NHibernate.ByteCode.Castle.dll file.")]
        public void CastleProxyLoads()
        {
            var dummy = new LazyFieldInterceptor();
            Assert.IsNotNull(dummy);
        }
    }
}

...在此之后，文件正确加载并编译了我的单元测试。

【讨论】：

【解决方案3】：

第一步是核对存储库的本地副本并重新克隆它。如果您正在部署一个分支，请在恢复包和首次构建之前切换到该分支。您将更好地了解问题的真正原因。

此处未列出的一种可能性是，如果您的测试项目是一个框架项目，但在同一解决方案中有一个 .NET 标准项目，则测试项目可能无法在干净的情况下找到标准项目的包引用克隆/恢复/构建。

【讨论】：