Файлы Visual Studio 2008 .dll не могут быть перезаписаны, доступ запрещен

Question

Это странно. Visual Studio 2008, похоже, не выпускает свой дескриптор для файлов .DLL, создаваемых для моего проекта, поэтому во второй (и последующий раз) сборку, когда Studio пытается перезаписать измененные файлы .dll, появляется ошибка отказа в доступе. Я также не могу скопировать / удалить рассматриваемый DLL-файл (Tasks.dll), пока Visual Studio открыта после того, как я его собрал. Process Explorer сообщает мне, что файл используется devenv.exe, поэтому я знаю, что Visual Studio не отпускает его после завершения сборки.

Кто-нибудь видел это раньше, и если да, что я могу с этим поделать? Очевидно, что открытие и закрытие Visual Studio между каждой сборкой не является приемлемым решением, и проблема сохраняется при перезагрузках системы.

Еще немного предыстории: я использую DLL проекта, вызывающего ошибки (Tasks.dll), в директиве UsingTask MSBuild другого проекта, назовем ее Test. Порядок сборки проекта устанавливается так, что Tasks создается перед Test, а затем задача TestBuild вызывает задачу из /bin/debug/Tasks.dll.

.

Answer 1

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

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

Мы не смогли реорганизовать проект для упрощения ссылок (слишком дорого), мы также не могли потратить больше времени на исследование проблемы, поэтому нашли обходной путь - не идеальный, но он помог нам, и мы годами используем его в этом проекте , Это немного сложно, но я постараюсь описать это:

1. Прежде всего - пример структуры проекта
   - MyProject (dir)
   - Бин (реж)
   * Proj1.exe
   * Proj2.dll
   * Proj3.dll
   - Src (реж.)
   - Proj1 (реж.)
   - Proj2 (реж.)
   - bin (dir)
   - Proj3 (реж.)
   - корзина (каталог)
   

2. Proj1 (который, предположим, является консолью / приложением Windows - * .exe) имеет выходной каталог, установленный в MyProject / Bin

3. Proj2 (.dll) имеет вывод сборки, установленный по умолчанию в MyProject / Src / Proj2 / bin / ... в событии postbuild мы копируем результат в «MyProject / Bin»

   copy "$ (TargetDir) \ $ (TargetName) .dll" "$ (SolutionDir) Bin"
   copy "$ (TargetDir) \ $ (TargetName) .pdb" "$ (SolutionDir) Bin"

4. Proj3 (.dll) имеет вывод сборки, установленный по умолчанию в MyProject / Src / Proj3 / bin / ... postbuild такой же как и для Proj2

5. А теперь ссылки. Допустим, Proj1 нужна ссылка на Proj2, а Proj2 нужна ссылка на Proj3.

   • впервые собрать только Proj3, так что в результате команд событий после сборки он будет скопирован в MyProject / Bin
   • Теперь в Proj2 добавьте ссылку на сборку MyProject / Bin / Proj3.dll (перейдите к файлу сборки, не ссылайтесь на проект). В зависимости от проекта вручную установите, что этот проект должен сначала собрать Proj3. Затем создайте «Proj2», чтобы он был скопирован в MyProject / Bin (команды событий после сборки)
   • и, наконец, в Proj1 добавьте ссылку на сборку MyProject / Bin / Proj2.dll (снова перейдите к сборке). В зависимости от проекта вручную установите, что этот проект требует Proj2 для построения первых. И теперь вы можете построить целое решение.

Основные проблемы с вышеуказанным подходом:

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

Answer 2

Самое простое, что вы можете сделать в этой ситуации, это использовать команду taskkill, чтобы убить процесс Visual Studio и все его дочерние процессы.

Вы можете вызвать это из командной строки или из PowerShell.

taskkill -IM devenv.exe /F /T

Два аргумента для /F orce и /T также убивают дочерние процессы.

ПРИМЕЧАНИЕ: введите taskkill -? в командной строке для получения дополнительной информации.