Problems with Report Viewer assemblies on production site - asp.net

Question

I'm having a weird issue with report viewer on my production site. I have a stage and demo version of the site deployed on the same machine. Recently I've been working on an update and have been deploying to the stage version which works fine. Today I deployed to Demo and suddenly the report viewer is broken, only on Demo.
The error I'm getting is:
CS0433: The type 'Microsoft.Reporting.WebForms.ReportDataSource' exists in both
'c:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.WebForms.dll'
and 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\h2o-demo\d354e6e4\ac3ce3e\assembly\dl3\67b85cd6\0027fec0_ed32ca01\Microsoft.ReportViewer.WebForms.DLL'
The project was updated from Report Viewer 9 to 10 in this update. All references in the Web Config have been updated as well as in my project's "References". I have noticed that the version that is getting put in "Temporary ASP.NET Files" is actually version 9 for some reason.
Again to recap; the project works fine on my local machine. It also works on the Stage site which is deployed on the same server as the broken Demo site.
Does anybody have any ideas on what I can do to troubleshoot this? I can't seem to find any resources that have solutions that are working for me. I tried the compilation batch = false and adding an assembly bindingredirect from 9 to 10 (though I suppose I could have done this incorrectly). I'm just really confused on why it would work on one site but not the other.
EDIT 1: After some more looking around I tried the binding redirect again. My config file now looks like this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-1.2.10.0" newVersion="1.2.10.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportViewer.WebForms" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="9.0.0.0" newVersion="10.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportViewer.Common" publicKeyToken="b03f5f7f11d50a3a" />
<bindingRedirect oldVersion="9.0.0.0" newVersion="10.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
The "Log4Net" redirect was already there and is the only thing there on stage. After adding the "WebForms" I got an error on "Common" and so I added that one too. Now I'm getting this error:
Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821' or one of its dependencies. The system cannot find the file specified.

Answer 1

This error looks like you have multiple assemblies, then corrected that issue by pointing to explicit GUID of assembly now you are missing one. Can you verify that the 'log4net' assembly even exists? I would take a look at an existing working SSRS system if you have one. See if that config is the same and if that file for the assembly exists. If it does you could always attempt a copy of it to the non working environment. In many cases assemblies or class libraries are either getting changed or overwritten by one installment over the other. Running multiple versions of similar products on one machine is hard at times.
I do it at home with SQL Server running on my Dev box for 2008 Enterprise, 2008R2 express, and 2012 Developer. I get lots of issues with hex errors and their pointing to problems where it cannot locate a file. The simple answer is don't install multiple versions of the same product on the same machine if you can help it but I know that is not always applicable for testing on the cheap or what you have. Generally with DLL issues with duplication I relist one to dllOLD or similar and see if it then works. If you are doing the more proper method and listing explicitly, which you are. I would just ensure the DLL's really exist and could remote to anther environment via RDP and have that screen up at the same time. Hopefully you have two monitors to see one environment compared to the other ;)

Answer 2

I figured it out. Turns out there was an old DLL hanging out in the Bin directory on the demo site. It wasn't getting overwritten with a new version because it's not in use anymore so it was just sitting there messing with the project somehow. I cleaned out the bin directory on the Demo site and then did a re-deploy and it worked fine. Thanks for the help guys.