There are certainly other ways to display the reports without using the ReportViewer control . I think they are probably going to show you requesting the report through a SOAP or URL Access call and then re-displaying it.
This would definitely be an option for you but does not tell us why your current methods don't work.
I have received your files and information. I will look at the files tonight, but want to clarify a few points from your message:
1) You say this: >>The application was built using .NET framework 2.0 (MS Visual Studio 2005 Professional Edition). No third party components/controls are used in this application.
... But I need to be sure not of how it was built but how it is configured in IIS: when you look in the IIS ASP.NET configuration information on both your laptop and the servers, which .NET version is the *application* actually set to use
2) The reason I asked what order things were installed in (in your case, IIS first and .NET second) is that sometimes the libraries that become default are different depending on which order they are installed. FWIW the order in which you think they were installed on this server box is *not* optimal, in my experience, and sometimes results in a lot of cleanup before things will work at all. See below.
3) Have we absolutely ascertained, in your case, that only *one* set of ReportViewer dlls is on each box and that they are exactly the same version (because there were patches for these guys as well, and the redist patches came out *later* than the dev versions.
4) I am also a little concerned that it looks like your various machines have different levels of patches for the XML components. Believe if or not this is significant. Please read this http://www.hutteman.com/weblog/2003/12/18-149.html and notice that there is a patch discussed about halfway down in the comments. Because this thread is pretty old I have no idea whether your servers could still have the bug, but it bothers me that your machines appear to have different KBs applied to the different machines. See below for some tests.
5) By reading this particular set of messages, you may also understand why I want to look at your RDLs directly, because how they were encoded and serialized might make a difference. I may or may not be able to "see" this.
OK. Here's a suggestion that should be pretty painless for testing further on your boxes:
It is sometimes possible to write a little ASPX page to test what the server sees and what is default. I don't know if this will help us in this case if the problem is in the way the ReportViewer control references the classes.
Here is a really simple example I put together to show you what I mean. Notice that I am testing both the MSXML COM libraries, I grabbed some very old code for this (which should be obvious from the ON ERROR handling!), and then I added some info about one dot net class -- you can pick whatever things you want to instance and check out what the application "thinks".
You can do this, on the server, within the context of the ReportManager application and your own web app. Do you get different results on your dev box and the servers
<%@ Page Language="VB" AutoEventWireup="false" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml" >
On Error Resume Next
Dim oXML As Object
oXML = Server.CreateObject("Microsoft.FreeThreadedXMLDOM")
If Err.Number <> 0 Then
Response.Write("MSXML 2.x or above is not available.")
Response.Write("MSXML 2.x or above is available.<BR>")
oXML = Server.CreateObject("MSXML2.DOMDocument.3.0")
If Err.Number <> 0 Then
Response.Write("MSXML 3.x or above is not available." & _
" (" & Err.Source & " " & Err.Description & ")")
Response.Write("MSXML 3.x or above is available.<BR>")
oXML = Server.CreateObject("Microsoft.XMLDOM")
oxml.setProperty ("ServerHTTPRequest", true )
If Err.Number <> 0 Then
Response.Write ("MSXML 3 or above is not default." & _
" (" & Err.Source & " " & Err.Description & ")" )
Response.Write( "MSXML 3 or above is default.")
oXML = Nothing
Dim oXMLDotNet As New System.Xml.XmlDocument, oType As System.Type
oType = oXMLDotNet.GetType()
Response.Write("<br/><br/>DotNet xmlDocument: <br/>" & _
Response.Write(oType.Module.FullyQualifiedName & "<br/>")
Response.Write(oType.Module.Assembly.ImageRuntimeVersion & "<br/>")
oType = Nothing
oXMLDotNet = Nothing
Again, we don't know right off the bat what classes to test, which should be classes ReportViewer is using internally. But we can add code to this simple test page to try to load your RDLs, using different .NET classes, and see what happens.
Also there might be something in the callstack of your errrors that might give us ideas of exactly what classes to try. I'm going to guess that we try XMLReader, but even if we get that right it might be something about how the instance is created (XmlReaderSettings) -- so who knows.
This is how I tend to try to track this type of cr*p down, at any rate. Maybe reading it will give you, or somebody else, some ideas...