NUnit & 探测路径

发布于 2024-08-01 22:14:05 字数 1718 浏览 2 评论 0原文

注意:这里的所有程序集都不是强命名的。

我正在使用 NUnit(尝试过 2.4.2 和 2.5.2)在程序集 A 中运行测试。程序集 A 引用程序集 B v2。 程序集 A 还引用程序集 C,而程序集 C 又引用程序集 B v1。

当我从仅包含程序集 B v2 的 bin\Debug 目录运行程序集 A 时,测试失败,并显示一条有关如何找不到程序集 B v1 的消息。

我尝试通过创建 assemblyA.dll.config 文件来解决此问题。 在该文件中,我指定了一个绑定重定向(即使我知道它们不适用于非强命名程序集)和一个探测路径,该路径应允许 NUnit 仅使用程序集 B v2。

不幸的是,我不断收到同样的错误。

我还尝试使用 FusionLogViewer 来检查绑定过程。

Assembly Binder Log Entry  (8/19/2009 @ 4:54:38 PM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  D:\svncheckout\gl\ext\win32\sourceforge\nunit-net20\2.5.2\nunit.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = ????
LOG: DisplayName = assemblyB, Version=1.0.3511.15236, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = .../bin/Debug
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Tests_1523525484
Calling assembly : assemblyC, Version=1.0.0.64031, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file:...\bin\Debug\assemblyA.dll.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Binding succeeds. Returns assembly from ...\bin\Debug\assemblyB.dll. (this is v2)
LOG: Assembly is loaded in default load context.

有什么想法吗?

Note: All assemblies here are not strong-named

I'm using NUnit (tried 2.4.2 and 2.5.2) to run tests in assembly A. Assembly A references assembly B v2. Assembly A also references assembly C, which in turn references assembly B v1.

When I run assembly A from a bin\Debug directory that only contains assembly B v2, the tests fail with a message about how assembly B v1 can't be found.

I try to solve this by creating an assemblyA.dll.config file. In the file, I specify a binding redirect (even though I know they don't apply to non strong-named assemblies) and a probing path that should allow NUnit to just use assembly B v2.

Unfortunately, I keep getting the same error.

I've also tried using FusionLogViewer to examine the binding process.

Assembly Binder Log Entry  (8/19/2009 @ 4:54:38 PM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  D:\svncheckout\gl\ext\win32\sourceforge\nunit-net20\2.5.2\nunit.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = ????
LOG: DisplayName = assemblyB, Version=1.0.3511.15236, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = .../bin/Debug
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Tests_1523525484
Calling assembly : assemblyC, Version=1.0.0.64031, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file:...\bin\Debug\assemblyA.dll.config
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Binding succeeds. Returns assembly from ...\bin\Debug\assemblyB.dll. (this is v2)
LOG: Assembly is loaded in default load context.

Any thoughts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

撩动你心 2024-08-08 22:14:05

作为附录,我有以下问题:我认为在处理非强名称程序集时,CLR 会加载并使用任何可用版本。 请参阅此专家 C++/CLI 页面。 如果这是真的,为什么 NUnit 首先抱怨无法找到程序集 B v1? 这是否与 NUnit 创建一个单独的 AppDomain 来运行测试有关?

As an addendum, I have the following question: I thought that when dealing with non strong-named assemblies, the CLR loads and uses any available version. See this page from Expert C++/CLI. If that's true, why is NUnit complaining about being unable to locate assembly B v1 in the first place? Does this have something to do with the fact that NUnit creates a separate AppDomain in which to run the tests?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文