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

Разобрался: служба Volume Shadow Copy почему-то отключена. Снова включил, и все вернулось на круги своя.

Answer 2

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

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

Answer 3

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

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

Если у вас всегда есть Copy to Output Directory as Copy, вы получите ошибку компиляции, упомянутую в вопросе. Если вы сделаете изменение, упомянутое выше, оно должно исчезнуть, и ваша 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

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

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

Answer 6

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

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

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