NUnit & 探测路径
注意:这里的所有程序集都不是强命名的。
我正在使用 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
作为附录,我有以下问题:我认为在处理非强名称程序集时,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?