Старый DLL файл продолжает использоваться

У меня есть, казалось бы, случайная проблема, когда мой проект будет работать с использованием старой версии DLL файла, который больше не существует. Иногда будет использоваться реальная версия DLL файла, в противном случае будет использоваться древняя версия DLL файла. Кто знает, где Visual Studio получает этот DLL файл - это месяцы устарели!

Я знаю, что он использует старый DLL файл, потому что, когда приложение запускается, я начинаю получать странные "TypeLoadExceptions", жалуясь, что методы не существуют или не имеют реализаций.

Иногда иногда помогают следующие действия:

Перезапуск Visual Studio
Перезапуск компьютера
Очистка и восстановление решения
Удаление всего в\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Временные файлы ASP.NET
Поиск и удаление экземпляров DLL файла в папке \Documents and Settings\имя_пользователя\Local Settings\Temp

Иногда я выполняю все вышеперечисленные шаги, и он по-прежнему использует старую копию DLL файла. Где это скрывает?!

Такая же проблема существует на нашем TeamCity сервере, который использует MSBuild. Когда TeamCity пытается запустить модульные тесты, он использует старый DLL файл.

Теперь я знаю, что я могу использовать перенаправление сборки в файле web.config, но номер версии DLL файла не изменился (я не хочу его обновлять, поэтому он просто остается в версии 1), Я не хочу запускать версию DLL файлов только для решения этой проблемы. Я просто хотел бы знать, какие конкретные кеши нужно очистить, чтобы я мог продолжить разработку.

Ответ 1

Он скрывает его в GAC. Там он может проживать бесконечно. Использование более поздней версии может действительно решить проблему, но в Visual Studio есть выдающаяся ошибка, которая связана с выбором правильной версии DLL файлов. (Если DLL Hell не было достаточно плохо, команда Visual Studio делает это хуже!)

Найти его в GAC сложно, и я не могу сообщить вам, как это сделать, но как только старая версия будет удалена, он не будет найден снова. Иногда, даже если вы указываете компилятор на более новую версию (по дате), она будет использовать более старую версию, потому что она имеет тот же уровень версии (по версии). Это его ошибка.

Ответ 2

Кто знает, откуда Visual Studio получает эту dll - это месяцы устаревший!

Окно модулей - ваш друг...

Он точно скажет вам, откуда этот файл. Вы можете даже использовать его с произвольными процессами, если вы присоедините отладчик.

Ответ 3

Я тоже думаю, что они прячутся в GAC. Вы можете посмотреть в "C:\Windows\assembly", чтобы увидеть все DLL и отменить регистрацию оттуда.

Ответ 4

Проблема может возникнуть с порядком сборки или вашими проектами. Если ваш тестовый проект создан до проекта приложения, это приводит к описанию поведения.
Чтобы исправить это: щелкните правой кнопкой мыши на своем основном проекте в VS и выберите Зависимости проекта... и проверьте порядок сборки. Изменения в подпоследовательности сборки могут быть сделаны здесь путем правильной установки этих зависимостей.

Ответ 5

У меня была аналогичная проблема (но без Visual Studio). Я загружаю .NET dll с помощью UnsafeLoadFrom. На одном компьютере (сервер терминалов) старый файл все еще используется, независимо от обновленных номеров версий и т.д.

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

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

Ответ 6

В моем случае это было вызвано переключением в режим Release, который имел другую конфигурацию (которая использовала другое расположение DLL).

Ответ 7

В моем случае я использую Visual Studio для публикации веб-сайта, и хотя я проверяю, что ссылка на файл DLL изменилась, но опубликованная библиотека DLL все еще устарела. Наконец, я Publish Web Profile и выбираю правильную конфигурацию (например, Debug - x86/Release - Any CPU), снова публикую, а затем DLL исправляется.

Ответ 8

Пока этот вопрос старый, возможно, кто-то снова наткнется на него в своем стремлении найти решение. В моем случае я получил ошибку CS0433 для страницы ASP.Net. После удаления содержимого в папках obj\и bin\проекта все заработало снова. Вероятно, это должно быть сделано с закрытой Visual Studio. Возможно также очистить эти папки в ссылочных проектах в том же решении (если они используются в проекте, а не извлекаются через Nuget).

Ответ 9

Возможно, DLL ссылается на другую папку. Это может быть даже на сетевом диске, если у вас есть один в вашей переменной среды PATH. Здесь, как Windows ищет DLL: http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx

Ответ 10

В моей Visual Studio 2015 я гарантировал, что список ссылок на пути проекта Visual Studio, вызывающий проблемы, пуст:

Ответ 11

Если вы обнаружите такую проблему, удалите файл Reference dll и файл расширения pdb, добавьте новые ссылки и перестройте ваш проект. Это часто происходит из-за отсутствия перестроения проекта, коммита и обновлений.

Ответ 12

В моем случае старая DLL была в

C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll

Это не было показано в c:\Windows\assembly.

Я выполнил поиск MyDLL на моем диске, и он обнаружился, как указано выше. В то время я отлаживал свое тестовое приложение и пытался удалить папку, которая не работала... не удалось... она была заблокирована Visual Studio. Мне пришлось прекратить отладку приложения, закрыть Visual Studio, а затем удалить папку. Задача решена!! Я не знаю, как моя DLL попала туда, но она не появилась там с тех пор, как я ее удалил.

Ответ 13

Я перепробовал массу вещей, включая переустановку VS 2107. Вы можете видеть, откуда загружаются файлы DLL, в окне вывода. Пройдя все мои поиски DLL проекта, я нашел его.

Очистка это работало для меня.

C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'

Я фактически удалил все файлы в:

C:\Users\YourUser\AppData\Local\assembly\

Ответ 14

Для меня исправлением было убедиться, что виртуальный каталог в IIS указывает на правильный каталог. У меня есть два проекта в моей системе, v4 и v5. Виртуальный каталог в моей системе dev указывал на каталог bin v4 вместо моего каталога bin v5 - упс!

Ответ 15

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