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

Ответ 1

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

Создайте это как консольное приложение С# и используйте его в разделе Pre-Build так же, как и исходное предварительное переименование (см. верхнюю часть исходного вопроса для деталей).

 using System;
 using System.IO;

 namespace VisualStudioLockWorkaround
 {
  class Program
  {
   static void Main(string[] args)
   {
    string file = args[0];
    string fileName = Path.GetFileName(file);
    string directory = Path.GetDirectoryName(args[0]);
    if (!Directory.Exists(directory)) //If we don't have a folder, nothing to do.
    {
     Console.WriteLine(String.Format("Folder {0} not found. Exiting.", directory));
     return;
    }
    if (!File.Exists(file)) //If the offending executable is missing, no reason to remove the locked files.
    {
     Console.WriteLine(String.Format("File {0} not found. Exiting.", file));
     return;
    }
    foreach (string lockedFile in Directory.EnumerateFiles(directory, "*.locked"))
    {
     try //We know IOExceptions will occur due to the locking bug.
     {
      File.Delete(lockedFile);
     }
     catch (IOException)
     {
      //Nothing to do, just absorbing the IO error.
     }
     catch (UnauthorizedAccessException)
     {
      //Nothing to do, just absorbing the IO error.
     }                                        
    }

    //Rename the executable to a .locked
    File.Move(file, Path.Combine(directory, String.Format("{0}{1:ddmmyyhhmmss}.locked", fileName, DateTime.Now)));
   }
  }
 }

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

обходной путь - отключить "исходный шаг", но не работает для меня).

Ответ 5

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

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

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

Ответ 6

Я увидел ответ на:

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

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

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

Ответ 7

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

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

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

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

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

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