Page 1 of 1

Differences between loading from mrt vs. dll

Posted: Mon Jan 26, 2009 2:11 pm
by Mike K7
Hi guys,

We have a report template which we've saved as dll from the designer. This report template defines 3 sections of the report, first theres the PageHeader section which get's its data from the HeaderData connection in the DataSource then there's the PageFooter section that get its data from the FooterData connection in the DataSource. These two section are always present and always look the same in all our reports. Finally, there's the 'Detail' section which can differ depending on the report being printed. It's data comes from the 'DetailData' in the DataSource. For this section there's a HeaderBand and a DataBand, each one is empty.
Depending on the report being printed there migth be 5 to 10 different columns that must appear in the 'Detail' section.

In our application this template it loaded via a call to

Code: Select all

StiReport.GetReportFromAssembly("ReportTemplate.dll); 
and programmatically we get a reference to the StiHeaderBand and StiDataBand (of the Detail section) and add the required number of StiText objects to them in order to build the 'Detail' section of reports.

The problem is that the renderer report doesn't show the data that the dynamically added StiText components are supposed of display but if we load the .mrt file instead of the .dll before going through the same code that adds the StiText programmatically, everything looks as expected.

Because of security issues we want to deploy only .dll files not .mrt to our customers. We're using Reports.NET 2008.2.300 from 13 October 2008. The template mrt file is set to use engine V2.

How can we make this work? Thanks a lot.

Differences between loading from mrt vs. dll

Posted: Mon Jan 26, 2009 5:22 pm
by Edward
Hi Mike,

Unfortunately there is no way to add somehow any new components to the compiled report. This is only possible to do before compiling. As far as the dll library contains compiled report classes then the answer is no and our hands are tied here.

Thank you.