Проблемы блокировки файла сборки в Visual Studio 2010

Question

У меня есть проект Visual Studio 2008, который я «обновил» до Visual Studio 2010. После обновления у меня было много проблем с проектом (проект, который был и остается в 2008 году, я мог бы добавить).

Первая проблема заключается в том, что сборка основного исполняемого файла блокирует исполняемый файл, что приводит к сбою при дальнейшем перестроении.Это описано в связанном вопросе: Visual Studio блокирует выходной файл при сборке , где я выбрал обходной путь:

if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"

За исключением того, что этот обходной путь работает точно один раз .После этого заблокированный файл также блокируется devenv.exe и должен быть перемещен.Я работал над этим, добавляя .1.locked, .2.locked и т. Д. Единственный раз, когда блокировки снимаются, поэтому файлы могут быть удалены , находится на выключении devenv.exe (это занимаетчерез несколько секунд после исчезновения интерфейса пользователь может удалить файлы).

Тот факт, что отладчик не нужно использовать, чтобы вызвать эту проблему, указывает на довольно серьезную проблему с системой сборки 2010 года.

Некоторые теории, я думаю, я могу обесценить:

• Антивирус или другие фоновые задачи: если бы это была проблема, казалось бы, 2008 год провалится.Однако, будучи полным, я удалил avast!система полностью безуспешна.

ОБНОВЛЕНИЕ: у этого проекта те же симптомы на компьютере без антивируса и утилиты резервного копирования.Машины в офисе работают под управлением XP SP3 32bit, мой локальный компьютер - Windows 7 64 bit.Похоже, это не зависит от ОС.

• Отладчик блокирует файл: все, что требуется для его воспроизведения, - это повторение процесса сборки без отладки.ProcessExplorer показывает, что devenv.exe является держателем блокировок, а не vshost, и уничтожение vshost.exe все равно не снимает блокировки.

У меня возникла вторичная проблема, которая начинает возникать после того, как файлыполучить блокировку: дизайнеры форм перестают загружаться с ошибкой «не удается найти сборку».Я подозреваю, что они связаны с более ранней проблемой блокировки, так как дизайнеры запускают до сборки, но внесение любых изменений и перестройка вызовет сбой всех дизайнеров с этой ошибкой (даже те, которые у меня быликак текущий вид).

Жалко смотреть форму рядом с белым экраном ошибок только потому, что вы изменили «dummy = 1» на «dummy = 2», где «dummy» абсолютно ничего не делает, кроме как принудительноперекомпиляция в совершенно не связанной сборке.

Обновление: я попробовал еще несколько способов: Включение пошагового выполнения .NET не проверено, поэтому проблема не в этом.Удаление .SUO (пользовательские опции решения) просто работает до тех пор, пока перезапуск обычно устраняет проблему (две сборки: первая, потому что нет заблокированного файла, и вторая, потому что она есть, но она может быть переименована сценарием).

Error   28  Unable to copy file "obj\Debug\PolicyTracker3.exe" to "bin\Debug\PolicyTracker3.exe". 
The process cannot access the file 'bin\Debug\PolicyTracker3.exe' because it is being used by another process.  

Answer 1

Пока для этого не появится патч, у меня есть следующий обходной путь.Просто позвоните, используя что-то вроде "C:\MyBin\VisualStudioLockWorkaround.exe" "$(TargetPath)" (заменив MyBin на место, где вы размещаете исполняемый файл).

Создайте это как консольное приложение C # и используйте его в разделе «Предварительная сборка» так же, как и исходное переименование предварительной сборки (подробности см. В верхней части исходного вопроса).*

Answer 2

Существует известная ошибка утечки дескриптора файла в функции пошагового изменения исходного кода .NET Framework. Легко избежать, отключив эту опцию в Инструменты + Параметры + Отладчик. Однако это вряд ли будет вашей проблемой, если вы не запустите отладчик.

Совершенно неясно, почему Visual Studio вообще заинтересован в выводе сборки, не говоря уже о загрузке и блокировке. Может быть, вы открыли .exe один раз? Удалите скрытый файл .suo в каталоге решений, чтобы быть уверенным. На connect.microsoft.com нет ни одного отзыва о вашей проблеме, я бы порекомендовал вам создать свой собственный. Им нужно что-то воспроизводимое, чтобы взглянуть на это, убедитесь, что вы включили пример проекта, демонстрирующий такое поведение.

Answer 3

К сожалению, переименование / перемещение заблокированного файла у меня не сработало (дескрипторы были открыты только с помощью FILE_SHARE_READ), но то, что сработало, это просто уничтожение этих (предположительно утекших) дескрипторов в процессе Visual Studio.Вы можете использовать KillHandle для автоматизации этого шага.

Answer 4

В моем случае у меня есть сильно настроенная сборка для расширения в Visual Studio 2010, которая без проблем работала в Visual Studio 2008. В какой-то момент сборки некоторые из выходных сборок загружаются в отдельный домен приложения для документациипоколение, а затем домен выгружен.Разгрузка домена работала правильно, что подтверждается проверкой списка доменов приложения до и после.

Похоже, что Visual Studio 2010 содержит блокировки дескрипторов файлов на любых сборках, загруженных с помощью API-интерфейсов Assembly.Load *, работающих на основе файлов и работающих нафайловые дескрипторы или пути.Я мог видеть, как дескриптор файла появляется в ProcessExplorer, как только выполняется Assembly.Load, и дескриптор так и не освобождается, даже после выгрузки AppDomain.

Я смог обойти проблему, загрузив необработанную сборкубайты с использованием FileStream и перегрузки byte [] Assembly.Load.

Answer 5

Уже в Ms Connect: http://connect.microsoft.com/VisualStudio/feedback/details/551819/vs2010-locks-static-library-after-debug-session

Обходной путь - отключить «пошаговое преобразование источника», но у меня не работает).

Answer 6

Я немного опоздал на вечеринку, но эта проблема возникла впервые после того, как мы обновились до VS2015. С VS2010 такого никогда не было!

Мы часто разрабатываем с несколькими экземплярами VS, открытыми одновременно - это приложение клиент / сервер, и мы вносим изменения в оба уровня одновременно.

После обновления до VS2015 два экземпляра VS будут «блокировать друг друга» из obj \ Debug, и один экземпляр окажется не в состоянии построить общие («общие») проекты, то есть наш DTO, инфраструктуру сущностей проекты.

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

В итоге я просто использовал разные конфигурации сборки решения для каждого решения (скопировано из Debug). Это создало новые специфичные для решения каталоги obj и bin и полностью исключило конфликты из-за dll, соответствующих общим проектам.

Надеюсь, это поможет кому-то еще.

Answer 7

Я видел ответ по адресу:

http://social.expression.microsoft.com/Forums/en-US/blend/thread/844dfea0-efa2-440d-97ce-49ac7108dae3

(см. Сообщение Навит Саксена)

Он упоминает о закрытии файлов XAML (проектных поверхностей), и это, похоже, работает для меня. Я знаю, что это не так уж и здорово, но по крайней мере мне не нужно перезагружать VS.