Visual Studio 2015 блокирует DLL во время отладки

У меня есть 3 С# проекта A, B и C. Оба A и B ссылки C. Ссылки на C из A и B устанавливаются в "Копировать локальную", подразумевая, что после того, как C построен на C.dll(в выходной каталог C), он копируется в выходной каталог A или B (в зависимости от того, что компилируется)

У меня есть 2 решения, SA и SB. SA содержит A и C, а SB содержит B и C. Я запускаю 2 экземпляра Visual Studio 2015. Я открываю SA в одном экземпляре и SB в другом.

Я нахожу, что если я начну отладку (F5) A из SA, а затем (пока A все еще отлаживает), сделайте замену на C из SB и попытайтесь скомпилировать SB, я получаю ошибку компиляции, указывающую, что C. dll нельзя переписать, потому что он используется другим процессом (экземпляр devenv.exe, на котором выполняется SA).

Это не имеет смысла для меня, потому что после компиляции C в C.dll и копирования в выходной каталог A, Visual Studio должна освободить блокировку файла.

Я проверил (через окно Modules в SA), что загруженная версия C.dll - это копия в выходной каталог A.

Это началось вчера, когда я начал использовать Visual Studio 2015 (вместо Visual Studio 2013).

Есть ли у кого-нибудь идеи? Мое текущее решение - запустить SA через CTRL-F5 (начать без отладки), но это становится раздражающим, когда я хочу одновременно запускать SA и SB в режиме отладки.

Спасибо.

UPDATE

Я изучил, почему функция "Изменить и продолжить" может привести к описанному поведению, и согласно этой странице https://msdn.microsoft.com/en-us/library/ms164926.aspx > Изменить и продолжить позволяет для внесения изменений в исходный код во время сеанса отладки и получения результатов, не останавливая отладки, перекомпиляции и перезапуска сеанса отладки (какова была бы суровая проблема, которая должна была быть). Если эта функция включена, Visual Studio может потребоваться перекомпилировать любую зависимую DLL в любое время, что объясняет блокировку.

Ответ 1

У меня была та же проблема. Я изменил настройки VS2015, и, похоже, проблема ушла:

отключен Опции\Отладка\Изменить и продолжить
-Options\Sourcecodemanagement от TFS до none -
-disabled Параметры\Отладка\Диагностика во время отладки -

Не знаю, какой из них вызвал блокировку, но я подозреваю, что у меня не было диагностических тестов, которые у меня не было в VS2013. (Имена настроек, которые я переводил с немецкого языка на английский, не знаю, точно ли они вызывается в версии на английском языке.)

Edit: Как было исследовано Shea, это была функция Edit-And-Continue, которая блокировала DLL.

Ответ 2

в моем случае это был "Panda бесплатный антивирус", который смотрел в DLL проекта "C", и это вызвало ошибку: "процесс не может получить доступ к файлу, потому что он используется другим процессом"

Ответ 3

У меня была такая же проблема, и ни одно из других рекомендуемых решений, с которыми я столкнулся при поиске в interwebs, работало для меня. Наконец, после "восстановления" Visual Studio 2015 Enterprise я попытался запустить Visual Studio в безопасном режиме: devenv.exe/SafeMode

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

Ответ 4

В моем случае файл .pdb был заблокирован. Это не то же самое, что .exe становится заблокированным, как и при отладке.

Предполагая, что это просто .pdb, просто переместите его в новую папку (я перетащил и опустил). Как ни странно, его нельзя удалить, но его, безусловно, можно перенести! Как только файл .pdb исчез, сборка снова смогла скомпилироваться.

Альтернативное решение (и, пожалуй, наименее удобно) подразумевает закрытие проекта полностью, а затем его снова открывать (файл .pdb волшебным образом разблокируется!).

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