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

Question

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

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

Окно Modules - ваш друг ...

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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