Guidance for using reports from an existing .NET Framework 4+ report library in a .NET Core application
|Product||Progress® Telerik® Reporting|
The class library that contains report definitions must target .NET Framework 4.0 or greater in order to provide design-time support in Visual Studio through the Visual Studio Report Designer. Such library cannot be referenced in a .NET Core project because .NET Core projects can reference only .NET Standard or .NET Core assemblies (see this post for detailed explanation). Therefore the existing type report definitions must be migrated to a .NET Standard or .NET Core class library. The drawback is that there is no design-time support for .NET Core or .NET Standard and the Visual Studio Report Designer cannot be used in such projects. This is mainly because of the current limitations of the framework and Visual Studio toolset (for example, ComponentDesigner class which is used as a base class for our components, is not yet supported by .NET Core framework).
There are two approaches to resolve the problem depending on the amount of custom code used in the report definitions.
If the report classes do not contain custom code (i.e. handlers for events like NeedDataSource, ItemDataBound, etc.) or this code can be substituted with conditional formatting and bindings in the report definition, it is recommended to use the Standalone Report Designer to import them into a set of .trdp/.trdx reports, as explained here. If the report uses class library assemblies that contain user functions or provide data for ObjectDataSource instances, their projects need to be migrated to .NET Standard. This way the Standalone Report Designer will be able to load the assemblies and provide design-time support for them. The produced .trdp/.trdx definitions can be used through a UriReportSource in a .NET Core application.
If the custom code in the report definitions must be retained, copy the code from .cs and .designer.cs files of your reports to a new .NET Standard or .NET Core library. Add references to NuGet packages for the missing classes (i.e. System.Drawing.Common for the PaperKind class) and remove all the references to VisualStudio-specific routines. Once the project compiles, the report classes it contains can be used through a TypeReportSource or InstanceReportSource in a .NET Core application.
It is recommended to use the first approach and migrate the reports to .trdp or .trdx report definitions, so the design-time support will be provided by the Standalone Report Designer.