NUnit: "Процесс не может получить доступ к файлу... потому что он используется другим процессом".

Я использую версию графического интерфейса NUnit, и она начала расстраиваться, когда у меня загружен тестовый проект, пытающийся проверить что-то. Если я вношу изменения в Visual Studio, а затем попытаюсь перестроить решение, он выдает сообщение об ошибке "Невозможно скопировать файл obj\Debug\foo.dll в bin\Debug\foo.dll. Процесс не может получить доступ к файлу bin\Debug\foo.dll, потому что он используется другим процессом.

Это DLL, которую я загрузил в GUI, конечно. Это было нормально, и просто обновляйте ссылку на проект после сборки, но теперь, похоже, это блокирует его. Как я могу вернуться к этому поведению?

Я попытался включить/отключить настройку теневой копии, кстати, с теми же результатами в любом случае.

VS2008 SP1 и NUnit 2.4.8, если это имеет значение.

Ответ 1

Выяснилось: служба "Теневая копия тома" была отключена по какой-то причине. Вернул его обратно, и все в порядке.

Ответ 2

Я просто хотел добавить, что перемещение файла проекта Nunit в место решения решило мою проблему. Мне не нужно было изменять настройки теневого копирования в nunit или включить службу теневого копирования.

См. "Переполнение стека" nunit lock dll

Ответ 3

У меня была та же проблема, что и в вопросе. Я решил это на своей машине следующим образом:

В Visual Studio > Solution Explorer > выберите DLL, вызывающую проблему > щелкните правой кнопкой мыши > выберите свойства. После этого действия свойства файла dll теперь должны быть видны.
В представлении свойств файла dll; установите Копировать в каталог вывода для копирования, если он более новый.

Если у вас есть Копировать в каталог вывода как Копировать, вы получите ошибку компиляции, указанную в вопросе. Если вы сделаете упомянутое выше изменение, оно должно исчезнуть, и ваша dll все равно будет скопирована.

Ответ 4

У меня была та же проблема:

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.

Причиной в моем случае было то, что я использовал одно и то же пространство имен в двух сборках:

MyNUnitTestLibrary "завернул" тестовые классы в "namespace bank {...}"
"NUnit Quick Start" также имел все внутри "namespace bank {...}"

Изменение одного из имен пространства имен устранило проблему. Я сделал несколько изменений в обеих сборках и повторно скомпилирован без ошибки

Обратите внимание, что обе сборки содержат тесты, поскольку я играю с NUnit.

Ответ 5

У меня тоже была эта проблема, но я изо всех сил пытаюсь воспроизвести ее сегодня. Как представляется, форумы предполагают, что это связано с тем, что ваш код не возвращает ресурсы, которые он использовал. Это звонит, так как я бы тестировал Xml-ридера, когда у меня была эта проблема.

Здесь ссылка, которую я нашел на asp.net

Ответ 6

У меня была эта проблема, и после многого чтения и экспериментирования я понял, что виновником на самом деле не было ничего в NUnit или моем коде. Это была другая библиотека, которую я использовал, FakeItEasy, фреймворк, который не смог правильно освободить все ресурсы.

Если вы используете FakeItEasy с NUnit и сталкиваетесь с этой проблемой, подумайте о переходе на другую структуру макета. Если вы не используете FakeItEasy или удаляете его из своего проекта, не исправить это, сделайте инвентаризацию всех сторонних библиотек, которые вы используете из тестового кода, и подумайте, может ли кто-нибудь из них что-то делать.

В качестве альтернативы, попросите создателя NUnit явно освободить любые ресурсы, хранящиеся в любой из собранных тестовых сборок, или если вы гораздо активнее, чем я, воспользуйтесь тем, что он является проектом с открытым исходным кодом и решение, которое делает это.