Ответ 1
Вам также нужно контролировать ссылки в проектах - ссылки компилируются в сборку и будут пытаться загрузить. Я предполагаю, что у вас устаревшая ссылка на сборку log4net, но используется последняя версия.
Мне было предложено взглянуть на ошибку в приложении ASP/С# с его интеграцией с Paypal. Полное полное сообщение об ошибке:
Не удалось загрузить файл или сборку 'log4net, Version = 1.2.0.30714, Culture = нейтрально, PublicKeyToken = b32731d11ce58905 'или одной из его зависимостей. Расположенные определение манифеста сборки не соответствуют ссылочной позиции сборки. (Исключение из HRESULT: 0x80131040)
Из того, что я понимаю, это означает, что фактический файл, расположенный (то есть log4net.dll в моем каталоге bin), не соответствует ожидаемой версии, основанной на некоторой конфигурации сборки. Проблема, с которой я сталкиваюсь, заключается в том, что я не могу найти, где этот файл ссылается.
У меня есть доступ ко всем файлам в корневом каталоге веб-сайта сайта и не могу найти файлы конфигурации, которые ссылаются на эту DLL. Где еще мне нужно искать, чтобы определить, что вызывает неправильное совпадение?
В качестве примечания я убедился, что версия DLL в каталоге bin обновлена, но, похоже, она ничего не разрешила.
Вам также нужно контролировать ссылки в проектах - ссылки компилируются в сборку и будут пытаться загрузить. Я предполагаю, что у вас устаревшая ссылка на сборку log4net, но используется последняя версия.
У нас была и эта проблема, когда мы перешли на VS 2010 и .NET 4.0, мы вообще не используем log4net, но я подозреваю, что что-то еще мы используем (возможно, Crystal Reports?), и я также подозреваю, что есть dll мы также используем 32-разрядную DLL, потому что, когда я изменяю параметр "Включить 32-разрядные приложения" в расширенных настройках пула приложений в IIS, чтобы "Правда", все снова работало.
У нас была аналогичная проблема с нашим веб-приложением. Мы перешли от древнего .NET 1.1 32-битного к .NET 4.0 64-разрядному.
Ошибка, которую я получал в рамках нашего одного из наших пользовательских элементов управления, была следующей:
ASP.NET runtime error: Could not load file or assembly 'log4net' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Мое предположение заключается в том, что мы собираем DLL в 64-разрядной версии, но ссылаемся на 32-разрядную dll? Я бы согласился с тем, что сказал выше Мэтт Палмерли - переключение пула приложений на 32-разрядный режим. УДАЛЯЕТ проблему, но вы все еще застряли в 32-битном пуле приложений. Мы хотели воспользоваться дополнительной памятью. 64-разрядная версия предложит пулы приложений IIS.
В конечном счете, мне не удалось выяснить, какая из сторонних DLL файлов действительно ссылается на log4net. Я заметил, что после сборки, хотя log4net.dll был скопирован в мой каталог "bin", и я сразу щелкнул по нему и понял, что он был связан с Apache Foundation - http://logging.apache.org/log4net/
В итоге я просто загрузил последнюю версию log4net.dll для .NET 4, добавил ее в качестве ссылки на мой проект веб-приложения, перекомпилировал и снова открыл пользовательский элемент управления, и ошибка исчезла.
Надеюсь, что это поможет
Вероятно, у вас есть последняя версия log4net, но есть проект, который ссылается на старый. Вы можете заставить все сборки, ссылающиеся на старую версию, ссылаться на новую версию, используя <bindingRedirect>
Подробнее о них вы найдете здесь: http://msdn.microsoft.com/en-us/library/eftw1fys.aspx
Если вы не знаете, какую конкретную версию перенаправлять, вы также можете использовать ряд версий и указывать их все на свою конкретную версию.
Такая же ошибка здесь, вот как мы исправили: загрузка последней версии .Net 4.0 log4net.dll из Apache и замена версии в папке bin работала для меня. Вы должны добавить ссылку на свой проект, чтобы сделать его постоянным. Вот ссылка: Apache
Перейдите в раздел "Загрузки", "Бинарники" и выберите новую версию ключа. После загрузки перейдите в папку .Net 4.0, чтобы найти файл .dll.
У меня нет никакой полезной информации о конкретной ошибке. Однако в случае, если вы не использовали их, несколько полезных утилит для помощи в этом типе проблем: Dependency Walker и .NET Reflector.
Средство проверки зависимостей может использоваться, чтобы увидеть, есть ли неожиданные модули, используемые сборкой log4net. И утилита Reflector показывает все виды полезной информации о сборках (включая версии, ссылочные сборки, не говоря уже о дизассемблированном коде).
Я также столкнулся с этой проблемой, и причина этого заключалась в том, что проект по какой-то причине вытаскивал log4net из GAC, поэтому вполне возможно, что версия в GAC не соответствует версии, на которую ссылаются ваш проект
Я собирался следовать рекомендациям Мэтта, чтобы включить 32-битные приложения в настройках пула приложений IIS.
Оказывается, мне даже не нужно было так далеко, ошибка была решена, как только я переключился на IIS из Cassini.
Чтобы переключиться на IIS:
Ошибка log4net для меня после этого.
Я не знаю, почему я получал его, потому что я даже не использую log4net в любом месте, но я рад, что он ушел.
После прочтения этих ответов я закончил проверку .csproj и нашел фактическую ссылку на "Lib\log4net.dll" в этом разделе. Я удалил это и скомпилировал проект.