NUnit:“该进程无法访问该文件...因为它正在被另一个进程使用。”

发布于 2024-07-23 00:12:05 字数 357 浏览 5 评论 0原文

我正在使用 NUnit GUI 版本,当我加载一个测试项目来尝试测试时,它开始让我感到不安。 如果我在 Visual Studio 中进行更改,然后尝试重建解决方案,它会抛出错误“无法将文件 obj\Debug\foo.dll 复制到 bin\Debug\foo.dll。该进程无法访问文件 bin\ Debug\foo.dll,因为它正在被另一个进程使用。”

当然,这是我加载到 GUI 中的 DLL。 以前是可以的,只需在构建后刷新项目引用即可,但现在似乎被阻止了。 我怎样才能恢复到那种行为?

我尝试过启用/禁用卷影复制设置,无论哪种方式都得到相同的结果。

VS2008 SP1 和 NUnit 2.4.8,如果重要的话。

I'm using the NUnit GUI version, and it started to get upset at me when I have a test project loaded in there trying to test things. If I make a change in Visual Studio, and then try to rebuild the solution, it throws the error "Unable to copy file obj\Debug\foo.dll to bin\Debug\foo.dll. The process cannot access the file bin\Debug\foo.dll because it is being used by another process."

This is the DLL I have loaded into the GUI, of course. It used to be OK, and just refresh the project reference after a build, but now it seems to be blocking it. How can I get back to that behavior?

I've tried enabling/disabling the shadow copy setting by the way, with the same results either way.

VS2008 SP1 and NUnit 2.4.8, if that matters.

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

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

发布评论

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

评论(6

南风起 2024-07-30 00:12:05

我遇到了与问题中提到的相同的问题。 我通过以下方式在我的机器上解决了这个问题:

  1. 在 Visual Studio 中 > 解决方案资源管理器> 选择导致问题的 dll > 右键单击> 选择属性。 执行此操作后,dll 的文件属性现在应该可见。
  2. 在 dll 的文件属性视图中; 将复制到输出目录设置为如果较新则复制

如果您将复制到输出目录设置为始终复制,您将收到问题中提到的编译错误。 如果您进行上述更改,它应该会消失,并且您的 dll 仍将被复制。

I had the same problem as mentioned in the Question. I solved it on my machine by the following:

  1. Within Visual Studio > Solution Explorer > select the dll that is causing the problem > right click > select properties. After this action the File properties of the dll should now be visible.
  2. Within the file properties view of the dll; set the Copy To Output Directory to Copy if newer.

If you have the Copy to Output Directory as Copy always you will get the compile error mentioned in the question. If you make the change mentioned above it should go away and your dll will still be copied.

伴我心暖 2024-07-30 00:12:05

我只是想补充一点,将 Nunit 项目文件移动到解决方案位置解决了我的问题。 我不必更改 nunit 中的任何卷影复制设置或启用卷影复制服务。

请参阅堆栈溢出 - nunit 锁定 dll

I just wanted to add that moving the Nunit project file to the solution location solved my issue. I did not have to change any shadow copying setting in nunit or to enable shadow copying service.

See Stack Overflow - nunit locking dll

温柔戏命师 2024-07-30 00:12:05

弄清楚了:“卷影复制”服务由于某种原因被关闭。 重新打开,一切恢复正常。

Figured it out: the "Volume Shadow Copy" service was shut off for some reason. Turned it back on, and everything's back to normal.

于我来说 2024-07-30 00:12:05

我遇到了同样的问题:

Unable to copy file obj\Debug\foo.dll to bin\Debug\foo.dll. 
The process cannot access the file bin\Debug\foo.dll because it is being used by another process.

在我的例子中,原因似乎是我在两个程序集中使用了相同的命名空间:

  1. MyNUnitTestLibrary“包装”了“命名空间银行{...}”中的测试类
  2. “NUnit Quick Start”也包含了所有内容“命名空间银行{...}”

更改命名空间名称之一修复了该问题。
我对这两个程序集进行了一些更改,并重新编译,没有出现错误。

请注意,这两个程序集都包含测试,因为我正在使用 NUnit。

I had the same problem :

Unable to copy file obj\Debug\foo.dll to bin\Debug\foo.dll. 
The process cannot access the file bin\Debug\foo.dll because it is being used by another process.

The cause in my case seemed to be that I used the same namespace in two assemblies:

  1. MyNUnitTestLibrary 'wrapped' the test classes in "namespace bank {...}"
  2. 'NUnit Quick Start' also had everything inside "namespace bank {...}"

Changing one of the namespace names fixed the problem.
I have made several changes to both assemblies and re-compiled without the error

Note that both assemblies contain tests,as I a play with NUnit.

温柔一刀 2024-07-30 00:12:05

我遇到了这个问题,经过大量阅读和实验后,我意识到罪魁祸首实际上并不是 NUnit 或我的代码中的任何内容。 这是我使用的另一个库,FakeItEasy,一个模拟对象框架,它无法正确释放它的所有资源。

如果您将 FakeItEasy 与 NUnit 结合使用并遇到此问题,请考虑切换到另一个模拟对象框架。 如果您不使用 FakeItEasy,或者从项目中删除它不能解决此问题,请从测试代码中盘点您正在使用的所有第 3 方库,并考虑其中是否有任何库可能执行类似的操作。

或者,纠缠 NUnit 的创建者明确释放它加载的任何测试程序集所持有的任何资源,或者如果您比我更主动,请利用它是一个开源项目的事实并提供一个解决方案这。

I had this problem, and after a lot of reading around and experimentation, I realized the culprit was not actually anything in NUnit or my code. It was another library I was using, FakeItEasy, a mock object framework, which was failing to properly release all it's resources.

If you're using FakeItEasy with NUnit and encounter this problem, consider switching to another mock object framework. If you're not using FakeItEasy, or if removing it from your project doesn't fix this, take an inventory of all the 3rd party libraries you are utilizing from the test code, and consider if any of them might be doing something similar.

Alternately, pester the creator of NUnit to explicitly release any resources held by any of the test assemblies it loads, or if you're much more proactive than I, take advantage of the fact that it's an open source project and contribute a solution that does this.

洒一地阳光 2024-07-30 00:12:05

我也遇到了这个问题,但今天我很难重现它。 论坛似乎表明这是由于您的代码没有归还它正在使用的资源。 这敲响了警钟,因为当我遇到这个问题时,我一直在测试 Xml 阅读器。

这是我在 asp.net 上找到的链接

I had this problem too, but I'm strugling to reproduce it today. The forums seem to suggest that it is due to your code not giving back resources that it was using. This rings a bell as I would have been testing an Xml reader when I had this issue.

Here's a link I found on asp.net

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