ActiveReports v6 → v18: how to migrate our runtime SectionReport generator

Posted by: triloknathn on 16 January 2026, 11:19 am EST

  • Posted 16 January 2026, 11:19 am EST - Updated 16 January 2026, 11:25 am EST

    Hello Support Team,

    We need guidance on migrating a legacy ActiveReports v6 (DataDynamics) SectionReport-based report generator to ActiveReports v18, so that newly generated reports render correctly in the AR18 JSViewer.

    Background (brief):

    • Generator: VB.NET, .NET Framework 2.0, ActiveReports v6 (SectionReport), programmatically builds reports and saves runtime-generated documents (.rdf).

    • Web Viewer: .NET Framework 4.7.2, recently upgraded to ActiveReports v18 Web Designer + JSViewer.

    *** Issue: Runtime-generated AR6 documents open in AR18 JSViewer but render incorrectly (body/charts/controls broken). Same documents render fine in AR10 viewer (now removed).**

    • Goal: Upgrade the generator to produce native AR18 documents. We do not need to convert old .rdf files.

    What we need help with:

    1. Conversion / tools

      Is there any official tool or library to convert AR6 SectionReport designer/code (including charts, CrossSectionBox, RichText, dynamic controls) to AR18?

    2. Upgrade path

      Is a direct jump from AR6 → AR18 supported for code-first reports, or is a staged upgrade (e.g., via AR10/14) recommended?

    3. API mapping & breaking changes

      Do you have documentation or examples mapping AR6 APIs (TextBox, ChartControl, GroupHeader/Footer events, SummaryGroup, DataField binding, etc.) to AR18 equivalents?

      Any known serialization or data-binding changes that commonly break runtime-generated reports?

    4. Designer vs programmatic layout

      Recommended migration approach:

      • Recreate reports in AR18 Designer and port runtime logic, or
      • Keep code-first generation and migrate APIs only?

        Are old designer files (.resx/.rpx) importable?
    5. Charts & RichText

      Known pitfalls migrating AR6 ChartControl to AR18 charting APIs?

      Any changes to RichText/RTF handling or recommended alternatives (we want to avoid Office interop)?

    6. Document.Save & JSViewer compatibility

      Once generated using AR18 runtime APIs, will saved documents be fully supported by AR18 JSViewer?

      Any recommended save/export settings?

    7. Runtime & framework requirements

      Is .NET Framework 4.7.2 supported for AR18 server-side report generation?

      Any server prerequisites (fonts, GDI+, native dependencies) we should plan for?

    8. Breaking-changes checklist

      A prioritized list of common AR6 → AR18 breaking changes that affect programmatic SectionReports (charts, grouping, subreports, CrossSectionBox, images, summaries).

    Our objective is only to migrate the generator so future reports are AR18-native and render correctly in AR18 JSViewer.

    Thanks in advance for your guidance.

    Regards,

    Trilok

  • Posted 19 January 2026, 3:25 am EST

    Hi Triloknath,

    Thanks for the detailed description of your query.

    1. For migrating the report files, you can use the convert tool. However, the convert tool might not work perfectly for your use case, as you are upgrading from a very old version.

    Please refer to the following pages of our documentation for more details on the convert tool: https://developer.mescius.com/activereportsnet/docs/developers/activereports-version-compatibility-migration/upgrade-reports-references/activereports-file-converter

    1. My suggestion would be to upgrade to ActiveReports 14 first and ensure everything is working fine, and then move to v18/v19.

    2. Do you have documentation or examples mapping AR6 APIs (TextBox, ChartControl, GroupHeader/Footer events, SummaryGroup, DataField binding, etc.) to AR18 equivalents?

    Any known serialization or data-binding changes that commonly break runtime-generated reports?

    We do not have any examples for this. However, for backwards compatibility, most of the properties should wok fine. You can check the breaking changes pages of our documentation from each version and move your way up from v12/v14 to v18:

    1. If it is feasible, we generally recommend recreating the reports using the newer version. This makes maintenance easier going forward and helps ensure better compatibility and future support.

    That said, we understand that in many cases this may not be practical. In such scenarios, it is completely acceptable to continue using the existing report definitions and code. And create all new reports with the designer only, and slowly recreate the reports(one by one) as needed.

    1. All the known pitfalls should be mentioned in the breaking changes and the upgrade section of our documentation:
    1. Once generated using AR18 runtime APIs, will saved documents be fully supported by AR18 JSViewer? Yes, RDF files can be opened in the JSViewer without any issues. Feel free to create a support case if you face any issues with viewing RDF files i the JSViewer.

    2. Yes, ActiveReports 18 is supported on .NET v4.6.2 to v4.8.1. See here: Product Requirement

    3. A prioritized list of common AR6 → AR18 breaking changes that affect programmatic SectionReports (charts, grouping, subreports, CrossSectionBox, images, summaries).

    You might face issues/warning in assigning Font and Image objects as we have removed dependency on System.Drawing from our code for functionalities such as image handling, text measuring, printing, etc. So, API dependencies such as:

    System.Drawing.Font and System.Drawing.Image in Section report have been removed from System.Drawing.Common.

    GDI references from GrapeCity.ActiveReports.Document.SectionReport, GrapeCity.ActiveReports.Document.SectionDocument, and GrapeCity.ActiveReports.Document.PageDocument classes have been removed.

    Apart from these changes, the priority should simply be to follow the breaking changes in version order, reviewing them sequentially from v12, then v13, v14, and so on, and then finally v18.

    Regards,

    Akshay

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels