Обновление приложения с помощью новой .net dll дает мне FileLoadException?

Question

У меня есть приложение .net 3.5 со многими dll, я пытался пересобрать конкретную dll без сборки всего приложения, но после замены старого новым выдает исключение, так как не может загрузить новую dll исключение: System.IO.FileLoadException: не удалось загрузить файл или сборку .... Насколько я понимаю, он ищет сборку с определенной версией и общедоступным токеном. Как решить эту проблему, не создавая приложение снова? также заявка подписана, но не зарегистрирована в GAC. P.S: Как я могу пропустить сборку приложения снова, или это необходимо, поскольку dll перестраивается?

Answer 1

Причина, по которой вы получаете ошибку, состоит в том, что ваша сборка подписана, и, скорее всего, для вашей ссылки на нее свойство Specific Version установлено в True, а номер вашей версии сборки, в которую вы внесли изменения, изменился.Я перепробовал много сценариев, и это был единственный сценарий, в котором я смог получить исключение FileLoadException.Если вы изменили Target Framework на более новую версию, например 4.0, вы получите вместо этого BadImageFormatException.Даже если вы говорите, что не меняли номер версии, все равно отметьте его или задайте для «Определенной версии» значение «Ложь», выбрав ссылку, щелкнув правой кнопкой мыши и выбрав свойства.

Вероятно, ваше исключение выглядело так:*

Could not load file or assembly 'LoadedAssembly, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=889080b75eb3bad2' or one of its dependencies. The located assembly's manifest
definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Но ваша скомпилированная версия, если сборка, на которую ссылается, больше не является 1.0.0.0 (или любой другой версией, например).На изображении ниже (немного меньше) вы можете видеть, что эталонное свойство ищет версию 1.0.0.0, для Specific Version установлено значение True, а эталонная сборка подписана и фактически является версией 2.0.0.0, что приводит к исключению FileLoadException.

Решите эту проблему, изменив номер версии и перекомпилировав ее, или установив для Specific Version значение False и восстановив только эту DLL.Вам не нужно перестраивать приложение целиком.

Answer 2

Вы пытались использовать переменную окружения DEVPATH ?Эта переменная среды позволяет вам определить каталог, который будет действовать как «GAC во время разработки» .Все, что вам нужно сделать, это:

1) Добавьте следующий элемент в ваш machine.config (проверьте, где будет находиться ваш machine.config)

• C: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG ИЛИ

• C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG *

2) Добавить новую переменную среды с именем DEVPATH

set devpath="e:\temp\Message_DLL\bin\Debug"     /// manually, console
/// or open windows config form - see below

3) Затем перейдите в приложение / проект пользовательского интерфейса и добавьте ссылку на свою dll в каталоге DEVPATH.

Убедитесь, что вы настроили "локальная копия = ложь, конкретная версия = ложь" .Как вы могли бы видеть Строгое имя (имя Старкера) - это true .

4) Теперь вы должны скомпилировать приложение UI РАЗ!После этого вы можете изменить свой источник в вашей DLL по своему усмотрению.Из-за переменной DEVPATH ваше пользовательское приложение всегда будет выбирать последнюю сборку вашей DLL!

ПРИМЕЧАНИЕ! Я пытался запустить приложение пользовательского интерфейса из VS, но потерпел неудачу с исключением загрузки.НО запускать его из окон проводника - успешно.Кажется, что запуск приложения пользовательского интерфейса из VS заставляет CLR искать указанную библиотеку в другом месте.

---

Также вы можете взглянуть на MSDN и MSDN2 .

Примечания: Используйте этот параметр только во время разработки.Среда выполнения не проверяет версии для сборок со строгими именами, найденных в DEVPATH.Он просто использует первую найденную сборку.

Вы также можете просмотреть следующие статьи / веб-страницы.

CodeProject - расположение сборки, привязка, развертывание

Социальные MSDN Вопросы о DEVPATH

Я думаю, что это должно сработать!

Answer 3

Windows EventLog должен предоставить больше информации о том, что не может быть загружено. Вы ввели другую зависимость в новую DLL? Я сталкивался с чем-то похожим, когда сторонняя DLL требовала установки C ++ Runtime 2005 (что имеет место на большинстве Dev-машин, а также на большинстве настольных компьютеров, поскольку это очень распространено).

Answer 4

Дикая догадка ... вы можете проверить, помечена ли папка, в которой находится DLL, только для чтения.

Щелкните правой кнопкой мыши папку> Свойства> , снимите флажок ReadOnly > нажмите Применить> выберите все подпапки и файлы> ОК.

Перестройте свое решение.

Answer 5

Вы должны восстановить эти сборки, ссылающиеся на эту новую DLL.