Further Information on Report Viewer Client Print Control bug

A while back I wrote a post about the “Unable to load client print control” error that Report Manager (and RSinteract) was throwing after Microsoft’s auto update KB956391.

I also asked a question over at StackOverflow which I ended up answering myself. Yesterday follow up information was added, which may be of use if you have trouble with the fix.

EY Kalman says:

I have had the same problem (on several different servers). Applying SP3 and Report Viewer SP1 has helped on some of the servers, allowing the client machines to connect and download the control with no problem. However, I have had one server that, even after applying the updates, when accessing the report viewer using a client machine, it was still giving me the error. On looking into the exact URL GET request that is being sent, I discovered that it is possible to force the client machine to connect directly to the Report Server to download the control.

The user would need to enter the following url:

http://reportservername/Reports/Reserved.ReportViewerWebControl.axd?ReportSession=51bjqv45xydgos2wghu5ceza&ControlID=7617dedbf0234f89b80cad8e64431014&
Culture=2057&UICulture=9&ReportStack=1&OpType=PrintHtml

This should then pop up the required download/install prompt.

dotnettrio added (which is probably more relevant to RSinteract):

Hi,

I got this working with out removing any patches. The above patch was not working too. Finally what I did was on the IIS server install the following patch and reset / restart the IIS server. This is not for report manager application. This is for any ASP.NET Web application developed in .net3.5 using VS2008 http://www.microsoft.com/downloads/details.aspx?familyid=6AE0AA19-3E6C-474C-9D57-05B2347456B1&displaylang=en

I hope this helps anyone else with this problem.

Leave a Comment

Obsolete Attribute and XML Serialization

   1: public class MyClass
   2: {
   3:     private string _internalProperty;
   4:     private string _newProperty;
   5:  
   6:     [Obsolete("This is no longer required, but needed for backwards compatability")]
   7:     public string Property
   8:     {
   9:         get { return _internalProperty; } 
  10:         set { _internalProperty = value; }
  11:     }
  12:  
  13:     public string NewProperty
  14:     {
  15:         get { return _newProperty; }
  16:         set { _newProperty = value; }
  17:     }
  18:   
  19: }

This is an interesting little anomaly in the way XML Serialization handles the “Obsolete” attribute on class properties when serializing to and from XML. The attribute is treated as an “XmlIgnore” attribute, meaning that the property is not serialized. It is well documented that adding the aforementioned attribute to a property in .NET 3.5 will cause this behavior, however, it is not mentioned in the same MSDN page for .NET 2.0 on the same subject.

This one caught me out. Apparently the only two ways to fix it are: to take the attributes off or use the “ShouldSerializeX” method constructs as demonstrated below…

   1: public bool ShouldSerializeProperty()
   2: {
   3:     return true;
   4: }

Leave a Comment