VS2012测试资源管理器锁定本机.dll，使重建失败

本文关键字：重建 失败 dll 本机 测试 资源管理器 锁定 VS2012 | 更新日期: 2023-09-27 18:15:04

我使用Visual Studio 2012作为c#和c++/CLI .dll的解决方案，c++/CLI .dll引用原生。dll，如boost。c++代码被编译为x64。

当我打开VS时，我可以清理和构建我的项目。

使用测试资源管理器，我可以运行测试。

一旦使用测试资源管理器运行测试一次，就无法重新构建项目。似乎VS2012测试资源管理器保持锁定我的c++/CLI-dll，在那里我得到以下错误:

LNK1104: cannot open file 'C:'Dev'LockExample'bin'Debug'cli.dll'

因此，每当我使用测试资源管理器运行测试时，我都需要重新启动VS2012才能继续开发。显然，这不是一个可持续的发展进程。

测试和重建工作没有问题，只有c#的dll -据我所知，问题只发生在使用本机x64代码的dll。

经过更多的测试，我发现这里的恶棍是vest .executionengine.exe。使用句柄(来自SysInternals)，我看到vstest.executionengine.exe持有cli-dll的.dll和.pdb的锁。它不为只管理的dll持有任何锁。

如何让Visual Studio Test Explorer在测试运行完成后释放c++/Cli dll上的锁?

VS2012测试资源管理器锁定本机.dll，使重建失败

在Visual Studio 2013中，这个问题可以很容易地通过取消选中菜单中"测试->测试设置"下的"保持测试执行引擎运行"选项来修复。

我在另一个帖子里找到了答案:vest .executionengine.x86.exe未关闭

经过一番搜索，我在connect.microsoft.com上找到了这篇文章。变通方法中的最后一个提示确实解决了这个问题，尽管它是一个丑陋的hack。

如果我将以下作为预构建事件添加到我的c++/CLI dll中，我可以重建:

taskkill /F /IM vstest.executionengine.exe /FI "MEMUSAGE gt 1"
taskkill /F /IM vstest.executionengine.x86.exe /FI "MEMUSAGE gt 1"

这将杀死vest .executionengine.exe进程，从而释放我的.dll文件上的锁。

我在测试涉及本地dll时也遇到过这个问题。变通方法(解决方案?)我发现的方法是在测试中添加deploymenttemattribute—不确定这是否普遍正确，但它确实对我有效。如果有很多这样的测试(我有6个)，这有点痛苦，但一旦完成，很容易复制并粘贴到其他测试。

所以我的单元测试类看起来像这样: 
[TestClass]
public class TestMyClass
{
    [TestMethod]
    [DeploymentItem("firstnative.dll")]
    [DeploymentItem("secondnative.dll")]
    public void TestMyMethod()
    {
        //Code which (indirectly) uses the above native dlls.
    }
}

我也一直在与这个问题作斗争，最初使用了"taskkill"解决方案，但我只是偶然发现了VS2013设置中的一个选项，似乎更优雅地解决了这个问题:

去掉

上的勾号

保持测试执行引擎在测试运行之间运行

工具/选项/Web性能测试工具

我已经编写了一个c#实用程序，可以在这里加载和卸载本地库我在下面的测试项目中使用了它。因为它在Dispose中卸载dll，所以我没有得到构建错误。

public interface INativeCrypto : INativeImport
{
    [ImportFunction("mynative.dll"]
    int NativeMethod();
}

[TestClass]
public class UnitTest1
{
    public void TestMethod1()
    {
        INativeCrypto impl = NativeImport.Create<INativeCrypto>("");
        // Use methods in impl
        int i = impl.NativeMethod();
        //...
    }
}

添加一些东西到@frodesto的答案中，(在VS2013的情况下)，"测试>测试设置>保持测试执行引擎运行"配置存储在用户配置(SUO文件)中。如果这个错误发生在TFS构建代理中，这可能会有点糟糕，因为它使用了一个服务默认用户。

要解决这种情况，首先杀死现有的vest .executionengine.exe，修改TFS构建代理使用的用户，使其与您登录的用户一起执行。打开存储在TFS构建代理工作区中的解决方案，并取消选择该选项。在此之后，TFS构建代理将读取"保持测试执行引擎"选项，因为SUO文件是针对同一用户的。

相关文章：