"Unable to find a version of 'Castle.Core-log4net' that is compatible with 'log4net 2.0.0'.

[JakeS]

I have a project that relies on both Castle.Core-log4net and Rhino.Servicebus.  We started the project long ago, before nuget arrived on the scene.  Our version of Castle Windsor is pretty severely outdated and we really should update to the latest stable release.  We also have decided we should be using nuget to manage our references better.  But it looks like the Castle.Core-log4net is referencing a specific (old?) version of log4net.

Here's how to reproduce our issue.  Start a new project.  Use nuget to install Castle.Core-log4net and all its dependencies.  Then use nuget to try and install Rhino.ServiceBus.Castle.  The second installation will fail with the error "Unable to find a version of 'Castle.Core-log4net' that is compatible with 'log4net 2.0.0'."  

What can I do to resolve this issue?  I've fought with this several times, trying to use binding redirects to sort things out, but the fact is that log4net DID make some minor changes between 1.2.10 and 1.2.11.  

Can I get a nuget package elsewhere?  Or am I going to be forced to build castle from source after pointing it at the newer log4net?

[Krzysztof Kozmic]

There's no official package for the new log4net and at this time we have no plans to provide one.

Feel free to build an unofficial one.

The solution I would personally recommend is to use NLog.

-- 

Krzysztof Kozmic

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/castle-project-users/-/qiBTxVRr6IsJ.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

[Jakub Leśniak]

Right now there are new official package versions for Log4Net.

http://www.nuget.org/packages/log4net/

Is there any chance that dependency on version 1.2.10 of Log4Net can be lifted to support i.e. 1.2.11 or 1.2.12 ?

There are important features in those new versions like ability to use connection string from web.config when using AdoNetAppender and some more.

I really would like to avoid creating and maitaining custom package if updating this one is possible and seems be as simple as changing one line in nuspec. I'm sure many people are waiting for this little change.

If there is any help needed with this I can do whatever is needed.

Thank you,

Jakub Leśniak

To unsubscribe from this group, send email to castle-project-users+unsub...@googlegroups.com.

[Krzysztof Koźmic]

Hey Jakub,

sorry about the late response, I was on holidays.

Long story short, there's no good solution to the problem, since either way (whether we upgrade the dependency or not) it'll break some users.

For now I don't think we'll make the switch to latest log4net for the 'official' package, but quick search shows that someone already created an un-official one for the 'new' log4net

https://www.nuget.org/packages/Castle.Core-log4net1211/

I haven't used it, and I don't know the person who created the package, but it looks like it may solve your problem.

cheers,

Krzysztof

[Jakub Leśniak]

Hello,

thank you very much for your response.

I would like to know the "long story" behind this. 

As far as my understaning goes: there's always the current version of the package, so old users are unaffected - nuget can easily be forced to use specific version of the package if the user wants to use Log4Net 1.2.10 for some reason.

There are two ways of doing the change - supporting only one version od Log4Net i.e 1.2.11 or making it support all the  newer versions - i.e.version  >=1.2.10. This way nuget can resolve the newest version possible, but things can break in the future.

I don't know which strategy is better, but it seems that having a version of this package for each version of Log4Net cannot do any harm. 

To sum up: what would be the reason not to upgrade?

Thanks,

Jakub Leśniak

[Роман Квасов]

Hello,

I have same issue as Jakub, some old projects depending on castle.core-log4net without clear path to upgrade.

Why just not upgrade log4net in castle.core-log4net and make release?

Exist users can continue use old package.

2013/10/31 Jakub Leśniak <kuba...@gmail.com>

To unsubscribe from this group and stop receiving emails from it, send an email to castle-project-u...@googlegroups.com.

To post to this group, send email to castle-pro...@googlegroups.com.

Visit this group at http://groups.google.com/group/castle-project-users.
For more options, visit https://groups.google.com/groups/opt_out.

[David Canning]

I'm with the rest on this, log4net 1.2.11 (the breaking one) has been out since Feb, I can't see a good reason not to move to the version with the new key.  I don't think the people at apache would be stupid enough to change the public key on the dll ever again.

[Chris Marr]

Thread resurrection - this attitude of not wanting to support log4net is making me not want to use castle any longer. Which is a shame, as I've not long started using it.

I want to use Topshelf and work nicely with castle, but seeing as the two cannot co-exist, it's become a dealbreaker for me.

[hammett]

There's no "attitude of not wanting to support log4net". Send a pull
request and we'll apply it. Just dont expect us to stop what we're
doing to fix this as a customer support request. Hate to break the
news to you, this is open source and we're all volunteering scarce
hours of our life.

>>>>> castle-project-u...@googlegroups.com.

>>>>> For more options, visit this group at
>>>>> http://groups.google.com/group/castle-project-users?hl=en.
>>>>>
>>>>>

> --
> You received this message because you are subscribed to the Google Groups
> "Castle Project Users" group.

> To unsubscribe from this group and stop receiving emails from it, send an
> email to castle-project-u...@googlegroups.com.

> To post to this group, send email to castle-pro...@googlegroups.com.

> Visit this group at http://groups.google.com/group/castle-project-users.

> For more options, visit https://groups.google.com/d/optout.



--
Cheers,
hammett
http://www.d-collab.com/
http://www.hammettblog.com/

[Chris Marr]

I'm glad to hear it - and I appreciate the time and effort that goes into developing OSS, my problem is that as a user of the software, we have a potential conflict of interest, and my ability to give anything back to the community will be severly hampered.

The attitude I talk about was in this previous comment:

"W dniu wtorek, 25 września 2012 03:33:27 UTC+2 użytkownik Krzysztof Koźmic napisał:

There's no official package for the new log4net and at this time we have no plans to provide one.

Feel free to build an unofficial one.

The solution I would personally recommend is to use NLog.

-- 

Krzysztof Kozmic

​"

I'm not saying that I expect customer support requests, and maybe my comment came across poorly (in my defense, I'd lost most of the day trying to get topshelf and castle log4net playing together), but when you search the internet, and the solutions look a little thin, things get fustrating. If you're saying that it's something the core development team will entertain, then fantastic. If it's something you'd consider merging, then I can approach my boss and tell him that there's some value (to us) in me spending some time on the project - but I think it's unlikely he'll allow it, and then we're back to that precious time again.

[hammett]

I'm sure Krzysztof would not oppose a PR with the proposed changes.

[Jonathon Rossi]

To follow on from Hammett, you have misunderstood the intent in Krzysztof's comment, he has been helping people with workarounds because this is a painful problem without a clear solution. Our position back in 2012 was that most people were still using 1.2.10 and we couldn't break that, so we were going to leave things as-is back then.

As Hammett said we are happy to accept pull requests, and others have attempted that in the past including Krzysztof himself, of which two were closed unmerged 3 weeks ago. Unfortunately I don't think anyone realised there is actually an breaking API change between 1.2.10 and 1.2.11 not just a strong name key change (i.e. a binding redirect isn't enough), and I only realised that recently when I dedicated part of my afternoon to getting this issue sorted.

#53 has all the details, #64 is the issue which only one person seemed to mind me closing the issue at this stage, I did also see one other that mentioned a workaround for TopShelf from 2012. I closed the issue rather than leaving it open because I wanted to see how many people actually were watching it and would pipe up to know how much of an issue it actually still is.

https://github.com/castleproject/Core/pull/53

https://github.com/castleproject/Core/issues/64

https://github.com/castleproject/Core/pull/73

https://github.com/castleproject/Core/pull/13

https://github.com/castleproject/Core/pull/19

https://github.com/castleproject/Core/issues/52

To get you out of your bind today, I'd workaround it by compiling Castle.Services.Logging.log4netIntegration.dll with the log4net that TopShelf wants to use, you could even commit the 10 source files into your source repo and keep them as part of your VS solution until we've got a solution.

If you've got any ideas of what we could do to solve this problem I'd love for you to post them on #64 so we can reopen it, but with our current tools I'm stumped getting a sane solution. If we can work out a solution we are happy to maintain, I'm sure I'll find some time to actually do the implementation.

Cheers, Jono

Jono