Page 1 of 1

log4net version mismatch?

Posted: Tue Aug 05, 2008 10:41 am
by Raconteur
Hi all,

We had a build that was running just fine until it was deployed to a production server. I have come in to help figure this thing out, and when I built the app on my development machine I get this error as well.

We are using the Avalara tax provider and have built the class per the instructions in this thread:
viewtopic.php?f=42&t=5935.

Essentially what is happening is when the code enters our Calculate function on our tax provider class, the first thing it does is to try to create a new instance of TaxSvc, which throws the following error and exits into the exception handler block:

System.IO.FileLoadException was unhandled by user code
Message="Could not load file or assembly 'log4net, Version=1.2.0.30714, Culture=neutral, PublicKeyToken=b32731d11ce58905' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
Source="AvalaraTaxProvider"
FileName="log4net, Version=1.2.0.30714, Culture=neutral, PublicKeyToken=b32731d11ce58905"
FusionLog="=== Pre-bind state information ===\r\nLOG: User = NT AUTHORITY\\NETWORK SERVICE\r\nLOG: DisplayName = log4net, Version=1.2.0.30714, Culture=neutral, PublicKeyToken=b32731d11ce58905\n (Fully-specified)\r\nLOG: Appbase = file:///C:/inetpub/wwwroot/AutoClub/\r\nLOG: Initial PrivatePath = C:\\inetpub\\wwwroot\\AutoClub\\bin\r\nCalling assembly : Avalara.AvaTax.Adapter, Version=4.13.0.0, Culture=neutral, PublicKeyToken=34e4ef76d6267205.\r\n===\r\nLOG: This bind starts in default load context.\r\nLOG: Using application configuration file: C:\\inetpub\\wwwroot\\AutoClub\\web.config\r\nLOG: Using host configuration file: C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\Aspnet.config\r\nLOG: Using machine configuration file from C:\\Windows\\Microsoft.NET\\Framework64\\v2.0.50727\\config\\machine.config.\r\nLOG: Post-policy reference: log4net, Version=1.2.0.30714, Culture=neutral, PublicKeyToken=b32731d11ce58905\r\nLOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/Temporary ASP.NET Files/autoclub/7e8e2cd2/b255792d/log4net.DLL.\r\nLOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/Temporary ASP.NET Files/autoclub/7e8e2cd2/b255792d/log4net/log4net.DLL.\r\nLOG: Attempting download of new URL file:///C:/inetpub/wwwroot/AutoClub/bin/log4net.DLL.\r\nWRN: Comparing the assembly name resulted in the mismatch: Revision Number\r\nERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.\r\n"
StackTrace:
at AvalaraTaxProvider.MyTaxClass.Calculate(Basket basket)
at CommerceBuilder.Taxes.TaxCalculator.Calculate(Basket basket) in C:\Users\Christopher Burns\Documents\Visual Studio 2008\Projects\CommerceBuilder\Taxes\TaxCalculator.cs:line 54
at CommerceBuilder.Orders.Basket.Recalculate() in C:\Users\Christopher Burns\Documents\Visual Studio 2008\Projects\CommerceBuilder\Orders\Basket.cs:line 955
at ConLib_Basket.Page_PreRender(Object sender, EventArgs e) in c:\inetpub\wwwroot\AutoClub\ConLib\Basket.ascx.cs:line 191
at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e)
at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e)
at System.Web.UI.Control.OnPreRender(EventArgs e)
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Control.PreRenderRecursiveInternal()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

I have gone as far as finding version 1.2.03x of log4net.dll on the Web, and tried building with that, but then it complained about wanting version 1.2.10.

Bear in mind that I am building on a 64-bit machine, but I believe the same problem arises on the production server which is 32-bit, running Windows Server 2K3.

Can anyone shed some light on this?

Any help greatly appreciated!

Cheers,

Chris

Re: log4net version mismatch?

Posted: Tue Aug 05, 2008 11:29 am
by sohaib
I think if you build with the lo4net.dll that ships with AC7 it should work... I guess you have already tried that?

Re: log4net version mismatch?

Posted: Tue Aug 05, 2008 12:49 pm
by Raconteur
Hi Sohaib,

Thanks for the response. Yes, we are building with the supplied log4net DLL, which is version 1.2.10. Every place that that DLL is referenced is using 1.2.10, and I cannot find anything pointing to 1.2.03x anywhere, which is why I thought it might be in the Avalara DLL.

Have tried posing the question to them as well, but was hopeful that someone here had seen this and solved it.

Will certainly post the solution here when I get it, for posterity.

Cheers,

Chris

Re: log4net version mismatch?

Posted: Tue Aug 05, 2008 2:06 pm
by afm
Try using a bindingRedirect to redirect 1.2.0.30714 to 1.2.10. I don't think the log4net API changes much (if at all), so it should work just fine.

Re: log4net version mismatch?

Posted: Wed Aug 06, 2008 2:21 pm
by Raconteur
Hi Andy,

Thanks for the input... this thing is killing me.

Here is how I did the binding redirect:

Code: Select all

<runtime>    
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>        
        <assemblyIdentity name="log4net"
                          publicKeyToken="b32731d11ce58905"
                          culture="neutral" />
        <bindingRedirect oldVersion="1.2.0.30714"
                         newVersion="1.2.10.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
This lives in the web.config for the entire site. Does that look right to you? It didn't seem to make a difference at all.

I got in touch with Avalara tech support and got this:
log4net.dll is an open source product that we use for xml logging. Unfortunatley, when the log4net people made the latest versions, they did not maintain backwards compatability, so later versions cannot be used with the Avalara dll.

Our next service upgrade, due in a few weeks, will include a version of the Avalara dll that is not dependent upon, nor using the log4net mechanism.

In the interim, he should be able to workaround the conflict by placing both versions in the Global Assembly Cache (aka GAC - that is precompile the .net dll using ngen.exe or gacutil.exe). Manifests and versioning both to be installed in the GAC.
From that I have tried running:

Code: Select all

ngen.exe log4net.dll
on both the 1.2.10 version and the 1.2.0.33710 version I found on the Net... still to no avail.

Can anyone shed any light on errors I have made here, or other ideas to try? I'm all out, aside from tossing Avalara for another tax provider.

Thanks!

Chris

Re: log4net version mismatch?

Posted: Wed Aug 06, 2008 6:23 pm
by afm
Your binding redirect looks good (although I don't think you need the public key token unless the assembly is signed...I don't think log4net.dll is signed).

You can turn on the Fusion log (search Google for how if you don't know) to see where ASP.NET is looking for the assembly. If the binding redirect is written correctly, you should see Fusion look for the new version.

But it is a moot point. The folks at Avalara are saying that even if you get the binding redirect to work, the new log4net.dll will not work because the method signatures have changed (or something other similar change that makes them incompatible).

Your only hope now is to stop using Avalara until the next release, or put both log4net.dll assemblies in the GAC. I've never used ngen to do that, but it is easy with gacutil. You can also use gacutil to make sure both are in the GAC (use the list command to verify that both are there). Then you can delete log4net.dll from the bin directory of your website. Then Fusion will find the correct version in the GAC.

Re: log4net version mismatch?

Posted: Wed Aug 06, 2008 6:58 pm
by Raconteur
Aha!!! Thanks, again, Andy.

I have already used NGEN to put both versions in the GAC but was still getting the same error... did not even think about the assemblies in the projects themselves. Let me try removing them and see what that does.

BTW - NGEN is dead simple... NGEN.exe <dll or exe filename>

Cheers,

Chris