PDA

View Full Version : log4net bindingRedirect



cdigs
05-10-2006, 09:02 PM
<runtime>
<assemblyBinding xmlns="urn&#58;schemas-microsoft-com&#58;asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="b32731d11ce58905" culture="neutral" />
<bindingRedirect oldVersion="1.2.9.0" newVersion="1.2.10.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

I'm wondering if I'm doing something totally, obviously, entirely wrong here...seems like the binding redirect is not being picked up by the runtime...


failed&#58; System.TypeInitializationException &#58; The type initializer for 'Spring.Context.Support.AbstractApplicationContext ' threw an exception.
----> System.IO.FileLoadException &#58; Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=b32731d11ce58905' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. &#40;Exception from HRESULT&#58; 0x80131040&#41;
----> System.IO.FileLoadException &#58; Could not load file or assembly 'log4net, Version=1.2.9.0, Culture=neutral, PublicKeyToken=b32731d11ce58905' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. &#40;Exception from HRESULT&#58; 0x80131040&#41;
at Spring.Context.Support.AbstractApplicationContext. .ctor&#40;String name, Boolean caseSensitive, IApplicationContext parentApplicationContext&#41;
at Spring.Context.Support.XmlApplicationContext..ctor &#40;String&#91;&#93; configurationLocations&#41;

Any insight would be appreciated...

cdigs
05-10-2006, 09:08 PM
Hmm...

Turns out that the publicKeyToken changed between the two versions.

New one is: 1b44e1d426115821

Old one is: b32731d11ce58905

Is bindingRedirect supported in this context?

Bruno Baia
05-10-2006, 11:36 PM
Actually, it smells like a new version of log4net :D
We should update to the 1.2.10.0 soon (not a beta anymore !!)

About the binding redirect, i heard assemblies must be signed with the same key otherwise the two assemblies will be treated as two distinct assemblies and not as an "upgrade".


-Bruno

cdigs
05-11-2006, 12:12 AM
Actually, it smells like a new version of log4net :D
We should update to the 1.2.10.0 soon (not a beta anymore !!)

About the binding redirect, i heard assemblies must be signed with the same key otherwise the two assemblies will be treated as two distinct assemblies and not as an "upgrade".

-Bruno

Bruno, that's my feeling, too, but I can't find firm documentation on this.

You're likely right; it would only make sense that different keys are used for different assemblies (but again, why can't they put this stuff in the SDK docs...ugh). This is what I suspected as well, but I'm not really sure why the log4net developers would decide to change the public key binding...I could understand if it was a major feature breaking release like 2.x or something, but it seems like it's mostly bug fixes and improvements with no code breaking changes.

I already did a build against 1.2.10.0 and all was fine. I've also sent out an email to the log4net mailing list to see if they have some workaround to this without requiring a rebuild...we'll see how that goes. I suspect they will say "rebuild against new version".

natl
05-12-2006, 03:02 PM
Can I get Spring.NET 1.0.2a with log4net 1.2.10?
:lol:

Mark Pollack
05-20-2006, 05:15 PM
Hi Nat,

Good idea. For 1.0.3 we can update to log4net 1.2.10, i.e. the latest stable release. I will post on the wiki the release date, probably in a few weeks time as this is actually a true point release (finally :) ) I made a JIRA entry (http://opensource.atlassian.com/projects/spring/browse/SPRNET-322) to keep track of it...

Cheers,
Mark

natl
05-22-2006, 12:58 AM
yeah go for it. But don't forget to add more information about bindingredirect for people who still have some binary dependent on log4net 1.2.9 BETA. So that they won't mess up their stuff with no idea what's going on

Erich Eichinger
06-03-2006, 01:31 AM
eeeh

maybe some more thoughts on this: since 1.2.9 has been around for quite a while i guess really many people are using it. and since the public key has changed, you would also break many people's code. redirection is not possible in this case!

maybe the log4net people just mixed up their keys. i couldn't find any hint regarding the key change on their website. i can't believe they're changing their key without any notice.

btw: of course i would like to update my projects to a point release. but in this case it's just not feasable. i would have to rebuild and deploy about 100 assemblies across all projects... - and i'm sure i'm not alone.

br,
Erich

MNBob
06-14-2006, 05:49 PM
I sent a message to the log4net user mailing list about this.

Erich Eichinger
06-21-2006, 01:46 PM
Hi all,

here's the statement of Nicko Cadell from the log4net mailinglist:



It was not my intention to change the strong name key for the 1.2.10
release. Due to some misadventure the key has changed between version
1.2.9 and 1.2.10. This has the undesirable effect of preventing binding
redirects between these version working.

I am still investigating where my key management procedures broke down.
But I think that it is now essential for log4net to examine our policy
towards strong naming, especially as this is supposed to be an open
source project. Does the private key form an integral part of the
'source'? It is not required to build an identically functional
assembly, but it is required to build an identical binary replacement
assembly.

At this point in time I think it is not possible to remedy the situation
by producing official builds of the latest version with the old strong
name, however it may be possible to make an unofficial build with the
old key for compatibility purposes. I think this will be driven by our
internal discussion on future strong name key policy.

Regards,
Nicko


br,
Erich

kimptoc
06-22-2006, 08:25 AM
Hi Mark,

Any news on the 1.0.3 release?


Hi Nat,

Good idea. For 1.0.3 we can update to log4net 1.2.10, i.e. the latest stable release. I will post on the wiki the release date, probably in a few weeks time as this is actually a true point release (finally :) ) I made a JIRA entry (http://opensource.atlassian.com/projects/spring/browse/SPRNET-322) to keep track of it...

Cheers,
Mark

Many Thanks,
Chris

kimptoc
08-19-2006, 08:11 AM
Hi,

Our workaround was to get the spring source and rebuild against log4net 1.2.10 - perhaps an alternate download should be available, so you can use either... at least until the correct way forward is sorted out...

Regards,
Chris

SteveG
04-07-2008, 05:07 PM
I'm currently using Spring 1.1 and NHibernate 1.2.1 using a redirect.

however, I'm not able to use log4net since NHibernate 1.2.1 is wanting Log4Net 1.2.10.0

This puts me in a bind.

Is there a way in Spring.net 1.2 to provide support for nhibernate 1.2.1 and log4net 1.2.10.0 ?

Thank you!

Erich Eichinger
04-07-2008, 05:14 PM
Hi,

Spring.NET is in no way linked to log4net. Instead it uses the Common.Logging (http://netcommon.sourceforge.net/doc-latest/reference/html/index.html) adapter library that allows you to configure any underlying logging system you prefer. For log4net 1.2.10 you need to use the adapter from assembly Common.Logging.Log4net (instead of Common.Logging.Log4net129)



<common>
<logging>
<factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter , Common.Logging.Log4net">
<arg key="configType" value="FILE-WATCH" />
<arg key="configFile" value="~/log4net.config" />
</factoryAdapter>
</logging>
</common>


-Erich

SteveG
04-08-2008, 01:03 PM
ah, excellent - works great.

Thank you!