Table of Contents

Migrating from SQL Server Reporting Services

ReportWright runs the reports you already have. This guide is for a team moving report files, data access and a viewer page from Reporting Services (or Report Builder with a local ReportViewer control) to ReportWright, and it says what moves as is, what needs a host decision, and what does not move.

1. Report files move as is

  • Copy the .rdl and .rdlc files into a folder the host serves (FileSystemReportStore) or into your own ReportStore. Nothing is converted: files stay in their schema version (2008, 2010, 2016) and keep every element the engine does not read. Saving from the designer writes the same version back.
  • RDL 2005 files view but keep their Table/Matrix/List regions unconverted; the engine refuses those regions (DXP9208). Open them once in Report Builder and save as 2008 or later, or wait for the upgrade command (register row U-C1).
  • Check What ReportWright supports for the items your reports use. The usual surprises: map legends and colour scales (named by DXP9409, not drawn), chart data labels and secondary axes (U-C3), gauge frames and gradients (U-C5).
  • Expressions run through DocWright's VB-dialect interpreter; =Code.… needs a host-supplied ReportCodeHost, otherwise the engine reports the refusal and the designer shows it.

2. Data sources become host decisions

Reporting Services stores connection strings in shared data sources on the server. ReportWright never ships a connection string to a client and never executes a query the report embeds without the host's say-so.

  1. For every data source name a report uses, add an entry to a DataSourceResolver that maps the name to a provider kind and the secret (ResolvedDataSource). StaticDataSourceResolver is enough for a fixed set; implement the abstract class to read a vault or a tenant table.
  2. Register the providers you need in AddReportWright (SqlServerDataSourceProvider, JsonFileDataSourceProvider, RestJsonDataSourceProvider, CsvDataSourceProvider, XmlDataSourceProvider, SystemDataDataSourceProvider).
  3. Queries run on the server with the router's limits (MaxRows, DefaultTimeout); a report's own CommandText is executed only through a provider you registered. OLEDB, ODBC and SSAS data sources do not move: re-point the report at a SQL Server, REST or file source.
  4. Design-time discovery (fields, preview, test) goes through the same resolver, so the designer's data pane works against your real sources without seeing credentials.

3. The viewer page

Replace the ReportViewer control or the /ReportServer iframe with the <ReportViewer Path="…" /> component (ReportWright.Blazor.Viewer). It runs in Blazor Server or WebAssembly; in WebAssembly the engine runs in the browser and dataset rows come from the host. Parameters, toggles, interactive sort, drillthrough, bookmarks, document map, search, print and every export are there (the viewer guide). A plain web client without Blazor uses the REST API (MapReportWright("/reporting")): run, pages as HTML fragments, region map, toggle, sort, search, export.

Differences you will see:

  • The HTML preview draws dotted, dashed and double borders solid (U-B1); the PDF draws them in their style.
  • Pagination is physical (the PDF's pages); there is no "interactive" soft-page mode yet (U-B2).
  • Fonts: the viewer's bundled metric fonts stand in for Arial, Times New Roman and friends in the browser; the server's PDF uses the machine's fonts. Embed the real fonts on the server for parity.

4. The designer

<ReportDesigner Path="…" /> (ReportWright.Blazor.Designer) replaces Report Builder for the items in What ReportWright supports. Every edit is an undoable command over the file's own element tree, so a report authored in Report Builder keeps everything the designer does not understand. The palette shows what the pinned engine cannot draw disabled, with the diagnostic code, rather than letting you author something that will not render.

5. Headless export and scheduling

POST /reporting/reports/export/{format}/{path} renders a report to PDF, PDF/A, PNG, JPEG, DOCX, XLSX, CSV or text in one request, with parameters in the body — the piece a scheduler or a mail job calls. In-process, the ReportWright.Samples.HeadlessExport sample shows the same through the libraries without a web host.

Subscriptions, schedules, data-driven bursting, the catalog, role-based security and the report server's management API are not part of 1.0 (Phase 8 in the plan); keep SSRS for those or run them from your own scheduler against the export endpoint.

6. Checklist

  • [ ] Report files copied; 2005 files re-saved as 2008+.
  • [ ] Every data source name resolved by the host; no OLEDB/ODBC/SSAS left.
  • [ ] =Code. blocks reviewed; a ReportCodeHost supplied or the code moved into expressions.
  • [ ] Items checked against What ReportWright supports; refused kinds replaced or accepted as gaps.
  • [ ] Viewer page swapped; border-style and font differences accepted or fonts embedded.
  • [ ] Export endpoint wired into the scheduler that used to call the report server.