Comment pour contourner maintien de log4net changeant publickeytoken

Question

Nous avons une asp.net 4.0 projet qui utilise un couple de cadres qui dépend de log4net version 1.2.10.0. Aujourd'hui, j'ai essayé d'inclure un nouveau cadre, qui dépend de log4net version 1.2.11.0, je suis coincé depuis:

log4net 1.2.10.0 a publickeytoken = 1b44e1d426115821

log4net 1.2.11.0 a publickeytoken = 669e0ddf0bb1aa2a

Depuis ces derniers sont différents, je ne peut pas utiliser de l'assemblée des redirections (à faire tous les cadres d'utiliser la même version de log4net) ou de la base de code (juste le nouveau cadre de l'utilisation de la version 1.2.11.0) par le biais de l'exécution de l'élément dans le web.config.

Quelles sont mes options ?

(et pourquoi le bip ne log4net changer publickeytokens entre les versions, ce que je comprends d'une clé perdue est la raison pour basculer entre la version 1.2.9.0 et 1.2.10.0, ont-ils perdu la clé encore une fois? Je vais bénévoles ma dropbox pour le garder en sécurité si ils en ont besoin...)

Edit: Ok, donc le log4net gars n'avait apparemment l'idée que la libération de deux touches est une bonne idée, mais cela signifie que chaque cadre vous utilisez des besoins d'accord sur qui des deux saveurs qu'ils préfèrent, ou de ces cadres ne peuvent pas travailler côte à côte dans le même domaine d'application. Suis-je le seul à trouver cette horrible idée? si tout le monde faisait cela, alors tout allait se briser en bas, à droite?

Edit2: Comme je l'ai dit, je ne suis pas à l'aide de log4net dans mon code, mais je me sers de plusieurs cadres qui dépendent de 1.2.10.0, et le problème se pose lorsque j'ai essayé d'utiliser un nouveau cadre, qui dépendait 1.2.11.0 (nouvelles clés), de sorte Stefans réponse ne s'applique pas, parce que le nouveau cadre permettra d'attendre la nouvelle clé, pas l'ancien

Answer 1

C'est de cette façon que j'ai des choses à travailler avec la version 1.2.11.0.

1. Malédiction apache pour changer la clef dans la première place :)
2. Télécharger la version de 1.2.11.0 signé avec l'ancienne clé.
3. Trier votre propre code en supprimant toute référence directe à log4net (nouvelles clés) et les remplacer par une référence à l'assembly signé avec l'ancienne clé.
4. Trier toute personne à charge assemblées vous pouvez avoir par l'inclusion de ce segment de votre site 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>

Answer 2

Vous pouvez télécharger une version de log4net 1.2.11.0 qui est signé avec l'ancienne clé. La raison pour laquelle le changé pour une nouvelle clé est expliqué dans la FAQ:

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

(En gros la nouvelle clé est disponible pour le public et pour une raison quelconque, ils ne veulent pas d'inclure l'ancienne clé dans la distribution. Il n'est pas clair pour moi pourquoi ils n'ont pas seulement faire de l'ancienne clé publiquement disponible)

Answer 3

Ne sais pas est-ce approprié pour votre cas particulier ou non, mais vous pouvez recompiler l’un cadres, de sorte qu’ils utiliseront log4net avec la même clé publique. Dans mon cas c’était FluentNHibernate qui utilise log4net 1.2.10 et Combres avec log4net 1.2.11 avec la nouvelle clé. J’ai téléchargé log4net 1.2.11 signé avec l’ancienne clé et recompilé Combress avec elle. Après qu’ajouté redirection de liaison de l’Assemblée de 1.2.10 à 1.2.11 et il commence à travailler.

Answer 4

Cela ne fonctionnera pas nécessairement dans tous les cas, mais parce que le projet qui a été à l’aide de log4net était OSS j’ai téléchargé la source, remplacé la version contradictoire de log4net avec la version j’utilisait et reconstruit le projet. Dans mon cas c’était Topshelf, donc j’ai maintenant une version de l’assembly Topshelf qui a été construit avec la même version de log4net que j’utilise, et maintenant je peux faire référence à tous les deux sans problème.