Otro problema más sobre los conflictos de log4net 1.2.11

He pasado las últimas 2 horas investigando estos problemas en SO, y parece que nada funciona.Otro problema más sobre los conflictos de log4net 1.2.11

Tengo una solución que utiliza log4net 1.2.11, a través de NuGet. Funciona bien en mi estación de trabajo de desarrollo de 32 bits que ejecuta Windows 7. No se ejecuta en mi sistema de prueba de Windows 2008 R2 de 64 bits. El error que consigo es:

Excepción no controlada: System.IO.FileLoadException: No se pudo cargar el archivo o ensamblado 'log4net, versión = 1.2.11.0, Culture = neutral, PublicKeyToken = 669e0ddf0bb1aa2a' o uno de sus dependencias. La definición del manifiesto del ensamblaje ubicado no coincide con la referencia de ensamblaje.

Estoy buscando en el directorio de la aplicación en mi sistema de prueba. El archivo log4net.dll allí es la versión 1.2.11.

La versión en el GAC era la versión 1.2.10. Lo he eliminado Había una versión en mi servidor de desarrollo que una vez más era otra cosa; Yo eliminé eso también. Yo he reconstruido; Me he redesplegado. He añadido

<dependentAssembly> 
    <assemblyIdentity name="log4net" publicKeyToken="669E0DDF0BB1AA2A" culture="neutral"/> 
    <bindingRedirect oldVersion="0.0.0.0-1.2.10.0" newVersion="1.2.11.0"/> 
</dependentAssembly>

a mi archivo de configuración. Nada parece hacer una pequeña diferencia. Mi proyecto de implementación muestra la versión correcta y la firma del ensamblaje log4net que se está implementando.

No sé qué más puedo hacer, pero me frustra bastante que una biblioteca de registro impida que se ejecute mi aplicación.

¿Qué me he perdido?

Fuente

2012-05-02 Jeremy Holovacs

Aquí estaba mi solución: Cambié de log4net a Common.Logging a NLog. No tomó mucho esfuerzo, y no creo que debería haber sido necesario, pero funcionó y funcionó bien.

Fuente

2012-11-30 00:00:38

Tuve que hacer lo mismo. El problema es cuando las dependencias requieren versiones conflictivas de log4net. –

Consulte la respuesta de @ keithl8041 para una solución real a este problema en lugar de una solución alternativa. :) –

@JohnySkovdal, en realidad yo también llamaría eso una solución. Eso significa que debe seguir usando una biblioteca en desuso y una clave de biblioteca anterior con un EOL claro. Eso limita tus opciones en el futuro. –

Estamos teniendo exactamente el mismo problema. Una dependencia en lo profundo de la base de código está poniendo 1.2.10 en el GAC y NuGet está tratando de usar 1.2.11. Dejamos de usar NuGet para log4net, demasiado dolor de cabeza. Parece que NuGet es un poco todo o nada.

Fuente

2012-10-25 04:18:55 Bart

Tuve este problema después de actualizar log4net a través de NuGet, solo para encontrar que la versión más reciente estaba firmada con una clave diferente. Suspiro. Por alguna razón, esto solo se hizo evidente cuando implementé en el servidor en vivo, no surgió en el desarrollo.

Puede obtener la versión 'oldkey' de the apache log4net site. Simplemente nukee sus referencias del archivo del proyecto y haga referencia a la versión antigua.

Fuente

2012-12-19 01:04:38 keithl8041

A veces hay que profundizar en las dependencias del proyecto. En mi caso, era una referencia de una referencia del proyecto de Service Stack real que hacía referencia a una versión diferente de Log4Net.

Para solucionarlo, agregué la versión más reciente de Log4Net desde nuget al proyecto ServiceStack. También me aseguré de que la referencia directa utilizara la versión más reciente y esto resolvió el problema.

Puede usar una herramienta de dependencia para encontrar rápidamente qué referencias usan versiones en conflicto, pero si no tiene una herramienta para esto, puede compilar la referencia del proyecto y ver qué versión de log4net.dll se copia al directorio

Fuente

2013-05-16 20:30:28 Despertar

Otro problema más sobre los conflictos de log4net 1.2.11

Respuesta

Cuestiones relacionadas