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

Question

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

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

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

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

Answer 1

Понял: служба «Теневое копирование тома» почему-то отключена. Включил его снова, и все вернулось на круги своя.

Answer 2

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

См. Переполнение стека - Блокировка узла dll

Answer 3

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

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

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

Answer 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.

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

1. MyNUnitTestLibrary "обернул" тестовые классы в "банке пространства имен {...}"
2. 'NUnit Quick Start' также содержал все внутри "банка имен пространства {...}"

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

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

Answer 5

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

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

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

Answer 6

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

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