log4net public token issues (could not load file or assembly)
We have some packages (and external modules) which we use who are using log4net.
But after installing these packages we have the following error:
Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Apparently umbraco depends on a log4net version without public key and the log4net (nuget package) has public key.
To use both log4net assemblies I solved this like this:
get the umbraco version of log4net.dll and move it to a new folder: bin\log4net-1.2.11-nokey
pull the new log4net nuget package (which is signed with a new key)
Add the code below to the assemblyBinding section of the web.config:
if you recompiled the log4net dll, you might need to update the publicKeyToken (you can use dotpeek or ILspy to find the publicKey easily.
This does not work for me (trying with log4net 1.2.13). And I wonder how it could work at all, since binding redirects normally are ignored for assemblies with no public key token - http://msdn.microsoft.com/en-us/library/2fc472t2.aspx. (The .NET 4.5 description varies substantially from the .NET 4.0 description, making it unclear whether the behaviour has changed)
And when it supposedly works: What happens when you have two log4net dll's flittering around in the same process? Will you have two e.g. FileAppenders competing over the same file?
And why, in the first place, did Umbraco choose to have a log4net with no PublicKeyToken? And why bundle it, instead of having it as a nuget package dependency?
I'm afraid this way does work with v1.2.13. You just need to set it correctly per DLL. I understand your frustration though.
I think they use log4net in this original since they have to do to allow it to work under medium trust. Apparently, they should be dropping this in v8 so we might see NLog or something else. Yes it's a very annoying issue.
Another big thanks for this, great use of binding redirects.
I nearly failed to get automated builds working because of this.
This is the post-build event I used to create an Umbraco folder in the output directly, taking a file within the project (lib\Umbraco.log4net.dll) as the source file
echo f | xcopy /y $(ProjectDir)lib\Umbraco.log4net.dll $(TargetDir)Umbraco\log4net.dll
And when will that be released? This has been broken for more than 3 years and causes significant pain any time someone needs to upgrade their Umbraco version. Surely a single breaking change to move to a more correct solution is better than having to hack in a fix with every upgrade?
Just to echo everyone else here - thanks so much!! I totally did not expect this to work, but it did. Wish I would have checked here sooner. Thanks again!
log4net public token issues (could not load file or assembly)
We have some packages (and external modules) which we use who are using log4net. But after installing these packages we have the following error:
Could not load file or assembly 'log4net, Version=1.2.11.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.Apparently umbraco depends on a log4net version without public key and the log4net (nuget package) has public key.
To use both log4net assemblies I solved this like this:
if you recompiled the log4net dll, you might need to update the publicKeyToken (you can use dotpeek or ILspy to find the publicKey easily.
Hope it helps someone!
This caused pain! Thank you so much :)
I knew it would help someone someday. :D
Nice, simple and effective solutions, thanks!
Thanks!!! you have saved my day!
This does not work for me (trying with log4net 1.2.13). And I wonder how it could work at all, since binding redirects normally are ignored for assemblies with no public key token - http://msdn.microsoft.com/en-us/library/2fc472t2.aspx. (The .NET 4.5 description varies substantially from the .NET 4.0 description, making it unclear whether the behaviour has changed)
And when it supposedly works: What happens when you have two log4net dll's flittering around in the same process? Will you have two e.g. FileAppenders competing over the same file?
And why, in the first place, did Umbraco choose to have a log4net with no PublicKeyToken? And why bundle it, instead of having it as a nuget package dependency?
I'm afraid this way does work with v1.2.13. You just need to set it correctly per DLL. I understand your frustration though.
I think they use log4net in this original since they have to do to allow it to work under medium trust. Apparently, they should be dropping this in v8 so we might see NLog or something else. Yes it's a very annoying issue.
Just had this problem!! Nightmare!!
Thanks for posting the solution, I think this needs submitting as a bug.
Oh and I used 1.2.13 and it does work. Just update the versions in the XML fragment supplied in the first post.
There is an issue logged about this: http://issues.umbraco.org/issue/U4-1324
Thanks for this! I'd hit the same issue.
Another big thanks for this, great use of binding redirects.
I nearly failed to get automated builds working because of this.
This is the post-build event I used to create an Umbraco folder in the output directly, taking a file within the project (lib\Umbraco.log4net.dll) as the source file
echo f | xcopy /y $(ProjectDir)lib\Umbraco.log4net.dll $(TargetDir)Umbraco\log4net.dll
Thank you for the fix. That problem cost me hours and hair loss.
Why is this still persistent in v7.3.7 Feb 16 I wonder?
Yes the problems will persist on every v7 release. Until v8 there won't be any fix for this as it would be a breaking change for many umbraco sites.
And when will that be released? This has been broken for more than 3 years and causes significant pain any time someone needs to upgrade their Umbraco version. Surely a single breaking change to move to a more correct solution is better than having to hack in a fix with every upgrade?
v8 release is planned for Q4 of 2016. Suffering is about to end. ;-)
V8 is currently planned for Q1 of 2017. But when we include the changing rotation speed of the earth spinning... the best guess is after codegarden.
Thanks for this solution. I thought I was going crazy!
Just to echo everyone else here - thanks so much!! I totally did not expect this to work, but it did. Wish I would have checked here sooner. Thanks again!
is working on a reply...