Как я работаю вокруг log4net, сохраняя изменения publickeytoken

У нас есть проект asp.net 4.0, который использует пару фреймворков, которые зависят от версии log4net 1.2.10.0. Сегодня я попытался включить новую структуру, которая зависит от версии log4net 1.2.11.0, с которой я застрял:

log4net 1.2.10.0 имеет publickeytoken = 1b44e1d426115821

log4net 1.2.11.0 имеет publickeytoken = 669e0ddf0bb1aa2a

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

Каковы мои варианты здесь?

(и почему сбой в log4net продолжает меняться в публикациях publiqueytokens между версиями, так как я понимаю, что потерянный ключ был причиной переключения между версиями 1.2.9.0 и 1.2.10.0, они снова потеряли ключ? добровольно удаляй мой пакет, чтобы он был в безопасности, если он в нем нуждается...)

Edit: Хорошо, поэтому у парней log4net, по-видимому, была идея, что выпуск с двумя ключами является хорошей идеей, но это означает, что каждая используемая вами фреймворк должна согласовать, какой из двух вкусов они предпочитают, или те рамки не могут работать бок о бок в одном и том же приложении. Неужели я единственный, кто считает эту ужасную идею? если бы все сделали это, тогда все сломалось бы, верно?

Edit2: Как я уже сказал, я не использую log4net в своем бизнес-коде, но я использую несколько фреймворков, которые зависят от 1.2.10.0, и проблема возникла, когда я попытался использовать новую структуру, которая зависела от 1.2.11.0 (новый ключ), поэтому ответ Stefans не применяется, потому что новая структура ожидает новый ключ, а не старый

Ответы

Ответ 1

Вот как я работал с версией 1.2.11.0.

Проклятие apache для изменения ключа в первую очередь:)
Загрузить версию 1.2.11.0, подписанную со старым ключом.
Отсортируйте свой собственный код, удалив любые прямые ссылки на log4net (новый ключ) и замените ссылкой на сборку, подписанную старым ключом.
Отсортируйте любые зависимые сборки, которые у вас есть, включив этот сегмент в свой файл web/app.config

   <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" culture="neutral" />
                <bindingRedirect oldVersion="0.0.0.0-1.2.10.0"
                                 newVersion="1.2.11.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>

Ответ 2

Я использую последнюю версию log4net, которую я загрузил через nuget. Однако для одной из библиотек, которые я использую, требуется старая версия. Мои проблемы привели меня к этому вопросу.

Проблема с другими ответами заключается в том, что они используют одну и ту же версию dll для всех привязок. Я хочу использовать функции в новой версии для всего остального, кроме устаревшей зависимости.

Чтобы сделать это, вам нужно сделать следующее:

Начните с загрузки старой версии (версия 1.2.11.0).
Переименуйте загруженный двоичный код в log4net.1.2.10.dll. Включите его в свой проект запуска с настройкой Build, установленной на None и "Скопировать, если новый",
Скажите .NET, где он может найти старую версию:

App.config

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" />
            <codeBase version="1.2.10.0" href="log4net.1.2.10.dll" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Атрибуты href определяют, где находится старая версия. Следовательно, все остальные запросы для log4net будут указывать на новую версию.

Ответ 3

Вы можете загрузить версию log4net 1.2.11.0, подписанную со старым ключом. Причина, по которой изменение в новом ключе объясняется в их FAQ:

http://logging.apache.org/log4net/release/faq.html#two-snks

(В принципе, новый ключ общедоступен, и по какой-то причине они не хотели включать старый ключ в дистрибутив. Мне непонятно, почему они не просто открывали старый ключ, хотя)

Ответ 4

Не знаю, подходит ли это для вашего конкретного случая или нет, но вы можете перекомпилировать одну из фреймворков, поэтому они будут использовать log4net с тем же открытым ключом. В моем случае это был FluentNHibernate, который использует log4net 1.2.10 и Combres с log4net 1.2.11 с новым ключом. Я загрузил log4net 1.2.11, подписанный со старым ключом, и перекомпилировал Combress с ним. После этого добавление связывания связывает перенаправление с 1.2.10 до 1.2.11 и начинает работать.

Ответ 5

Это не обязательно работает во всех случаях, но поскольку проект, который использовал log4net, был OSS, я загрузил исходный код, заменил конфликтующую версию log4net версией, которую я использовал и перестроил проект. В моем случае это был Topshelf, поэтому теперь у меня есть версия сборки Topshelf, которая была построена с той же версией log4net, которую я использую, и теперь я могу ссылаться на оба без проблем.

Ответ 6

Я попытался перейти к ссылкам, приведенным выше, но похоже, что все ссылки на сайте Apache не работают. Затем я решил решить эту проблему:

Из вашей Visual Studio используйте Nuget для загрузки и установки последней версии log4net (1.2.13.0). Менеджер пакетов NuGet автоматически загрузит и обновит всю версию log4net (1.2.11.0) до последней версии.