VS2010 не всегда выпускает dll перед сборкой

Question

У меня периодически возникает проблема при сборке с Visual Studio 2010. Иногда он отказывается строить с сообщением об ошибке вроде:

Ошибка 102 Не удалось скопировать файл "xxxxx \ Debug \ Services.dll" в "bin \ Debug \ Services.dll". Процесс не может получить доступ к файлу «bin \ Debug \ Services.dll», поскольку он используется другим процессом.

Единственное найденное мной средство - перезапустить Visual Studio. Закрытие решения недостаточно. Я пытался найти виновника с помощью Process Explorer, так как подозревал, что один из моих собственных потоков не закрывался должным образом. Однако этот процесс является devenv.exe, то есть самой Visual Studio. Также я получаю этот симптом только с VS 2010, даже при создании обновленных проектов VS 2008. Я никогда не сталкивался с этой проблемой в тех же проектах под VS 2008.

У меня есть много пользовательских пользовательских элементов управления WPF, и у меня есть теория, что именно дизайнер WPF иногда поддерживает зависимые от элемента управления библиотеки DLL, когда они должны выпускать их для сборки. Теория не очень хорошо обоснована, так как это периодическая проблема, и иногда она возникает без открытого замысла. У меня также есть та же проблема для проекта Windows Forms. Иногда я провожу день без заблокированных dll. Иногда это любая другая сборка или около того.

Я спросил Microsoft о проблеме, и они сказали мне сделать дамп Visual Studio и отладить дамп. Я не считаю это разумным советом.

Кто-нибудь испытывал нечто подобное? Это действительно раздражает.

Обновление 1

Поскольку это, похоже, ошибка в Visual Studio, и Microsoft ответила, что они не собираются ничего с этим делать, я хотел бы призвать всех, кто работает с пользовательскими элементами управления, проголосовать за эту ошибку на connect.microsoft.com. .

Об ошибке сообщается здесь: https://connect.microsoft.com/VisualStudio/feedback/details/587281 и мной здесь https://connect.microsoft.com/VisualStudio/feedback/details/568672

Обновление 2 Я собрал простой макрос Visual Studio, который закрывает все файлы .XAML перед сборкой. До сих пор я не испытывал блокировки с этим макросом. Добавьте следующий макрос в Visual Studio и назначьте его любимому ярлыку сборки. Может быть, а может и нет, это решит проблему.

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE90a
Imports EnvDTE100
Imports System.Diagnostics

Public Module CloseXamlAndBuildModule
    Sub CloseXamlAndBuild()
        For Each myDocument As EnvDTE.Document In DTE.Documents
            If myDocument.Name.EndsWith(".xaml") Then
                myDocument.Close()
            End If
        Next
        DTE.Solution.SolutionBuild.Build()
    End Sub

End Module

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

Я действительно сообщил об этой проблеме в Microsoft Connect некоторое время назад, но некоторое время не проверял ее.Мой оригинальный отчет для Microsoft: здесь .

Среди комментариев - способ воспроизвести проблему с помощью пользовательских элементов управления (как я подозревал).

Microsoft только что ответиластандарт «спасибо за ваш отзыв, ваше предложение не соответствует критериям, которые необходимо учитывать».Спасибо Microsoft.Полагаю, мне придется просто перезагружать Visual Studio пару раз в час.