In HTML5 Report Viewer it is possible to intercept a client request (e.g. the request to export a report to a particular export format) and modify it like this:

{"format":"<script>alert(1)</script>","deviceInfo":{"enableAccessibility":false,"enableSearch":true,"BasePath":"/COAT_SIT/api/reports"},"useCache":true,"baseDocumentID":"31d0a1ca0162a3f13e92bf"}

The malicious script will be executed when the error message for a missing export format is displayed in the viewer.

When the user confirms changing the chart type through the "Change Chart Type" dialog window, the graph designer does not get refreshed and still shows the old chart type.

Underneath the graph item is actually changed and if the report is previewed, the new graph layout will be displayed. The current workaround is to refresh the graph designer by changing one of its properties that cause full item refresh - Culture, Graph title, NoDataMessage, etc.

Under Linux, when the font is set with Conditional Formatting some of the TextBoxes may be rendered with different that the expected Font in Docx. Other TextBoxes set with the same rule to the same font are rendered correctly.

The same report rendered in Docx under Windows produces the correct document.

As virtually every product with 10+ years of development, Telerik Reporting has a certain amount of legacy code that was considered immutable at the time of writing. During the refactoring of our codebase to make it compatible with .NET Standard, we introduced a few types from System.Windows.Forms namespace to substitute the ones missing in the current version of the framework. Such types are System.Windows.Forms.CheckState and System.Windows.Forms.ControlPaint. Some of these types are introduced in recent release of .NET Core 3 for Windows Forms and therefore a conflict occurs between the types in our assemblies and the ones declared in .NET Core. The error is thrown in compile-time and it is similar to the one shown below:

The type 'CheckState' exists in both 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'Telerik.Reporting, Version=13.2.19.918, Culture=neutral, PublicKeyToken=a9d7983dfcc261be'

In a future release of our product this collision will be avoided by using a dedicated enumeration for the duplicated types. A possible workaround would be to add an extern alias to the assembly reference of Telerik.Reporting. In this case all the references to Telerik.Reporting have to be edited to use the new alias, but the code that refers to the actual types from System.Windows.Forms will remain unchanged.

Here is how the Telerik.Reporting reference would look like in the application .csproj file:

  <ItemGroup>
    <Reference Include="Telerik.Reporting">
      <HintPath>..\..\..\Bin\netstandard2.0\Telerik.Reporting.dll</HintPath>
      <Aliases>telerikReporting</Aliases>
      </Reference>
  </ItemGroup>

Using the alias means that all the types in Telerik.Reporting namespace must be accessed with this alias. Unfortunately this also applies to C#/VB report definitions - their types must also be prepended with the alias, which could require significant effort. Here is a sample code file that initializes the WinForms Report Viewer and examines the CheckState of a CheckBox control in the form:

extern alias telerikReporting;

using System;
using System.Windows.Forms;

namespace WindowsFormsCoreDemo
{
    public partial class MainForm : Form
    {
        public MainForm()
        {
            InitializeComponent();
            this.Load += this.Form1_Load;
        }

        private void Form1_Load(object sender, EventArgs e)
        {
            this.reportViewer.ReportSource = new telerikReporting::Telerik.Reporting.UriReportSource()
            {
                Uri = "SampleReport.trdp"
            };

            this.reportViewer.RefreshReport();
        }

        private void CheckBox_CheckedChanged(object sender, System.EventArgs e)
        {
            if (this.checkBox.CheckState == CheckState.Checked)
            {
                this.reportViewer.RefreshReport();
            }
        }
    }
}

The problem is not getting the error via Dot Net programming, but the complete layout destruction of the report as a result of the fact that a picture (in our case a thumbnail of a provider) is unavailable. Catching the report error is not an option. It is too complicated and even if we succeed  in obtaining the error, it will be very complicated to remove the unavailable url on the fly and re-render the report again. 

This seems to be a "known issue" for about 8 years!

My question: Is it possible to keep the remaining report "intact" if such an error occurs? This shouldn't be too difficult for the development team..

When merging the ReportViewer's WPF theme dictionaries from the DLL in App.xaml, the VS2019 Designer fails due to a problem with a ZoomComboBoxStyle definition.

This causes all Telerik UI for WPF control's styles fail to load in the Visual Studio designer.

WORKAROUND

Instead of App.xaml, merge the ReportViewer's theme dictionary closer to the control.

For example in the ReportViewer's direct parent:

When you try to send the report through the SendMailMessage functionality but an exception is thrown, the report will disappear. If you click on Refresh and try again with fake data, the exception will be thrown but the report will remain. If you prefer to refresh it automatically, you can use the error event:

var viewer = $("#reportViewer1")
.telerik_ReportViewer({
    serviceUrl: "api/reports/",
    reportSource: {
        report: "Report Catalog.trdp",
    },
    error: function (e, args) {
        console.log("This event handler will be called after a page of the report is ready.");
        console.log("The error message is: " + args);
        viewer.refreshReport();
    },
    viewMode: telerikReportViewer.ViewModes.INTERACTIVE,
    scaleMode: telerikReportViewer.ScaleModes.SPECIFIC,
    scale: 1.0,
    enableAccessibility: false,
    sendEmail: { enabled: true }
}).data("telerik_ReportViewer");

As in Ticket with ID 1440072 requested we are looking for a funktionallity to send Reports via E-Mails with the WPF ReportViewer. As only the HTML-5 ReportViewer currently supports the E-Mail sending we would request the feature for WPF as well.

Best Regards,

Martin

The print functionality cannot be used in Google Chrome 77.0.3865.75 (lastest update).  The following error is displayed in the console of the browser: Resource interpreted as Document but transferred with MIME type application/pdf.

As an alternative, you can use other web browsers for printing.