Rhino.Queues NuGet Package does not specify log4net version

[Torkel Ödegaard]

Hi,

Just thought I would notify you, if you are not already aware that due
too a log4net nuget update on december 21st the Rhino Servicebus
package is now broken.

When installing latest Rhino.ServiceBus nuget package you also get
installed log4net 1.2.11.

Rhino ServiceBus / Rhino Queues 2.2.2 is compiled against log4net
1.2.10. Log4net 1.2.11 differ in PublicKeyToken so no assembly
redirect will work.

The Rhino.Queues nuget package does specify a version for its log4net
dependecy, that is why nuget will take the latest version.

Regards
Torkel

[Corey Kaylor]

I have updated log4net in the latest nuget publish.

Torkel

--
You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.
To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.

[Marko Lahma]

This new version of log4net if quite problematic I'm afraid. They've
released this version with different strong name (again) so as noted,
it's impossible to do redirects if you have a library depending on
different version. How about relying on Common.Logging instead? That
way it would be possible to use log4net, NLog and Enterprise Library
logging (*shivers*) just by changing provider. Quartz.NET and
Spring.NET use Common.Logging for example. Common.Logging has kept the
same public key and API is compatible between versions.

Cheers,

-Marko

On 27 tammi, 22:53, Corey Kaylor <co...@kaylors.net> wrote:
> I have updated log4net in the latest nuget publish.
>
> On Wed, Jan 25, 2012 at 9:23 AM, Torkel Ödegaard

> <torkel.odega...@gmail.com>wrote:

[Jeffrey Becker]

I other than being able to use whatever logging system we wanted I dont see how this would help.  Common.Logging has the same issue and as of Tuesday or so they hadn't updated their builds either.

[Marko Lahma]

True that Common.Logging needs release for each log4net version, but
they only need to publish new adapter DLL so version doesn't need to
change at all.

-Marko

[Steve Sheldon]

I don't think this will be a problem going forward.  At some point log4net lost the SNK file with versions 1.2.9 and 1.2.10.  With 1.2.11 they made a decision to keep it in their source repository.

[Oren Eini (Ayende Rahien)]

Steve,

They lost the SNK for 1.2.9, then the (different) SNK for 1.2.10

[miles]

Hi,

I was having some problems with ESB / Rhino.Queues in this regard - I'm using the newer binaries in a project but need to integrate it with some older code that is tied to the old log4net version, and so am getting lots of binding failures.

I've made a version of Queues using Common.Logging instead of log4net - is the patch useful?

Thanks,

Miles

[Corey Kaylor]

I'm tempted to just create a logging abstraction similar to the way Caliburn does and would be the least amount of change to the codebase and remove logging dependencies entirely.

--

You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/WdjgSbUHS2wJ.

[Jakub Berezanski]

I second the idea of using Common.Logging - a couple of libraries already use this abstraction. Its API is inspired by log4net, so changes would probably be minimal.

To post to this group, send email to rhino-tools-dev@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-dev+unsubscribe@googlegroups.com.

[miles]

Hi,

Ok, so I adjusted queues and esb to work in the same way as Caliburn, and it's all working fine for me in production for a while now: the changes were far smaller than my need to get it working!

So,I've made a fork with the changes hoping that the change is still acceptable, and I can submit a pull request for it shortly.  The forks are here:

https://github.com/mr-miles/rhino-queues
https://github.com/mr-miles/rhino-esb

What's the best way to package things up to retain some backwards compatibilitty?  In particular, the new implementation does no logging unless configured to do so, whereas previously logging was all done by log4net. 

I was thinking that I already have some wrapper classes to support log4net, so I could make an additional project in the codebase to contain this.  Then by adjusting the nuget packages so there's a "rhino.queues.core" package and a "rhino.queues" package (which depends on rhino.queues.core and log4net) consumers should not be affected by the change.  The same approach would then apply to servicebus.

Any thoughts on this?

Thanks,

Miles

To post to this group, send email to rhino-tools-dev@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-dev+unsubscribe@googlegroups.com.

[Corey Kaylor]

I would like to pull these in. However, can you have a look at the contribution guidelines linked below and then submit a pull request.

http://hibernatingrhinos.com/open-source/rhino-service-bus/how-to-contribute 

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/7NFNUfxxv-8J.

To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.

[Miles Waller]

No problem - I hadn't seen that page!

Miles

>>>> To post to this group, send email to rhino-t...@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> rhino-tools-d...@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/rhino-tools-dev?hl=en.
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Rhino Tools Dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/rhino-tools-dev/-/7NFNUfxxv-8J.
>>
>> To post to this group, send email to rhino-t...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> rhino-tools-d...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/rhino-tools-dev?hl=en.
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Rhino Tools Dev" group.

[Nathan Palmer]

As a note the way Common.Logging is used in RhinoETL is that there is no logging unless the factory is set for Log4Net or NLog (or something else I guess.) The command line running though is setup for Log4Net. I'd assume RhinoESB would be the same setup.. all the logging is there but until a factory is set you won't get anything.

Nathan Palmer

To view this discussion on the web visit https://groups.google.com/d/msg/rhino-tools-dev/-/7NFNUfxxv-8J.

To post to this group, send email to rhino-t...@googlegroups.com.
To unsubscribe from this group, send email to rhino-tools-d...@googlegroups.com.

[Corey Kaylor]

Okay, I hate to throw in the towel on what Miles has already done, but I can see this being problematic down the road. This is my fault and I apologize. I think I'll give in to the majority wanting Common.Logging. Any takers on making the change? I will have time myself later this week, but if someone is motivated before then I would appreciate the help. After the logging changes are in I plan to run the delivery options enhancements in our own private nuget repo for the next week and if all looks good I will release the 2.0 nugets that following week.