加载some.dll时出错:无法加载测试容器'e:\ some.dll'或其中一个依赖项

时间:2012-11-29 15:49:07

标签: visual-studio-2010 pinvoke mstest

我有一个VS2010 C#项目,它引用了一大组本机.dll(商业java运行时)。这些文件在项目中被引用为“内容”文件,因为需要随项目一起复制。

使用PInvoke调用这些库中的代码,没有程序集引用。

每次编译解决方案时,Visual Studio测试框架都会尝试加载所有引用的dll文件,期望找到可能包含单元测试的.net程序集。由于没有.net程序集,因此抛出以下异常:

  

加载some.dll时出错:无法加载测试容器'e:\ some.dll'或其中一个依赖项。如果将测试项目程序集构建为64位程序集,则无法加载它。构建测试项目程序集时,请为平台选择“Any CPU”。要在64位处理器上以64位模式运行测试,必须在“主机”选项卡中更改测试设置,以便在32位进程中运行测试。错误详细信息:无法加载文件或程序集'file:/// e:\ some.dll'或其依赖项之一。该模块应包含一个程序集清单。

这需要花费很多时间,我想告诉Visual Studio不要尝试加载这些文件。

如何告诉Visual Studio停止尝试加载这些文件?

4 个答案:

答案 0 :(得分:2)

如果我弄错了,请纠正我: 您将P / Invoke目标二进制文件包含在VS解决方案中,因为您希望在构建解决方案时将二进制文件复制到目标目录。您需要这个,因为一旦构建VS解决方案,项目就会从目标目录执行。正确的吗?

VS软件包(默认和第三方)通常会尝试熟悉解决方案内容并遵循某些触发器(难以自行控制和控制)并以自己的方式加载解决方案和项目内容。在这个领域的战斗中投资回报率低于采用简单的工作(下图)。

虽然我无法向您提供有关如何告诉VS的测试包不加载所有二进制文件的权威答案,但我建议将这些二进制文件从项目中删除为“内容”,并将它们保留在源代码管理中它们今天的位置。添加一个构建后任务,将所述二进制文件复制到目标。这仍然会给你与今天工作相同的结果,但是,这些二进制文件无法用于测试探针。

答案 1 :(得分:0)

您只需右键单击解决方案名称并单击“Configuration Manager”即可查看配置设置 它将打开Configuration Manager的弹出窗口。 检查您的项目使用的平台是否最好选择任何CPU。 希望这可以帮助。试一试:) 因为这就是你所引用的箴言所说的 感谢

答案 2 :(得分:0)

我试图重现这个问题,发现根本原因是你已经将你的测试项目设置为编译为!AnyCpu。是否有任何特殊原因可以将此用于托管测试代码?

因此,除非您更改此内容,否则您将继续看到此消息。

如果要继续对测试项目使用此配置,则需要按照消息中的建议更新.testsettings文件。

答案 3 :(得分:-1)

对不起,如果这似乎是补救措施。为了完整起见,我把它包括在内。

一般图书馆行为

可以在项目文件中引用库(因此编译器会注入代码以加载引用),也可以在运行时使用LoadLibrary()或PInvoke调用动态引用库。加载引用的库时,运行入口点的函数可以依次加载它所依赖的库。加载库时,Windows将搜索一组众所周知的路径,包括%WINDIR%\Assembly和当前目录。 Wikipedia about this上有很多很好的概念信息。我建议阅读它。

可能的根本原因

如果您在构建应用程序,构建测试或执行任何一项测试时遇到问题,我无法从您的问题中得知。通常我不希望PInvoke导致编译错误。

  1. 应用构建期间出错: VS通常会向您显示您对无法找到的DLL的引用。但是,您可能缺少满足所有依赖项所需的DLL。要解决此问题,只需添加对缺少的DLL的引用即可。 (这是最简单的问题,所以我猜这不是你所看到的。)
  2. 测试构建期间出错:由于您的测试将引用您的应用程序/库,因此它也需要具有相同的引用。通常,确保获得所有内容的最简单方法是删除所有引用并添加对正在测试的项目的引用。对于某些测试,您可能需要一些额外的库,但不是您的app / lib本身。这些需要单独添加。
  3. 应用程序执行期间出错:启动应用程序时可能会发生这种情况,或者稍后在使用后期绑定时调用外部库时会发生这种情况。
  4. 测试执行期间出错:这可能与应用程序执行时相同。但是,测试也可以“部分构建”,仅执行少量测试。在这些情况下,某些文件可能无法复制。使用[DeploymentItem()]属性,您可以指定测试要求测试或app / lib项目中存在某些文件才能运行。 MSDN描述了如何做到这一点。
  5. 分辨率

    对于#1& #2解决方案在于调整项目中的参考文献 #3& #4,它可能会变得棘手。关于Windows Mobile here,您可能会发现一个类似的问题,您可能会发现它很有用,特别是指使用dumpbin列出库依赖项。您还可以使用procmon中的SysInternals来监视编译或加载期间的文件访问,以查看找不到的文件。然后,您可以包含丢失的文件,也可以删除引用它的库。

    祝你好运。希望这会有所帮助。