Enyim.Log4netAdapter mismatch

I have noticed an issue with the log4NetAdapter that is bundled with the zip package from the getting started page.

There seems to be a discrepancy between the packages available on nuget.org and the zipped package.

The assembly: Enyim.Caching.Log4NetAdapter (version supplied in the zip package (Available at: http://packages.couchbase.com/clients/net/1.2/Couchbase-Net-Client-1.2.7.zip) is built against Enyim.Caching version although version is supplied in the package.

The same assembly supplied by nuget.org is built against Enyim.Caching version
I am able to use logging only if I retrieve it via nuget. Using the zipped package available for download always results in a TypeInitializationEnxception.

If I am doing something wrong please let me know. Also please let me know if I need to supply any more details.

Pieter Prinsloo

Hello Pieter,

It looks like you found a packaging issue, I have logged it into our JIRA:

So you can follow it to see when it will be fixed.

Thanks for raising this.


Based on the last comment added to the JIRA:
"This was a recently found issue in the .NET client 1.2.7, but we’ve fixed it already in the source. It should be fine in 1.2.8 which we’re hoping to release within the next week. "

I am still seeing an issue in 1.2.9 this as well. Here is the output from IL DASM. you’ll notice it’s still referencing 1.2.7 for Enyim.Caching

// Metadata version: v4.0.30319
.assembly extern mscorlib
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4…
.ver 4:0:0:0
.assembly extern Enyim.Caching
.publickeytoken = (05 E9 C6 B5 A9 EC 94 C2 )
.ver 1:2:7:0
.assembly extern log4net
.publickeytoken = (66 9E 0D DF 0B B1 AA 2A ) // f…*
.ver 1:2:11:0
.assembly Enyim.Caching.Log4NetAdapter
.custom instance void [mscorlib]System.Reflection.AssemblyTitleAttribute::.ctor(string) = ( 01 00 18 43 6F 75 63 68 62 61 73 65 2E 4C 6F 67 // …Couchbase.Log

hhop -

This is confirmed, it’s a bug in our build script that creates the zip file. The work around ATM, is to use Nuget to get the packages and we will resolve this issue in the 1.3.0 release planned for the first week of November.