18 Answers, 1 is accepted
ASP.NET Core Class Library projects are not supported. Reporting engine is built against full .NET framework, therefore, it cannot discover types in .NET Core Class Library project. We will update our documentation to include this information as well.
The solution is to keep custom data objects in full .NET Class Library project.
Regards,
Katia
Progress Telerik

Katia,
Thanks for the confirmation.

We use Microsoft service (ITypeResolutionService form the System.ComponentModel of the .NET Framework) to resolve the types. The service cannot discover the .NET Core ClassLibrary types, hence we cannot resolve types from .NET Core projects.
Note that the ObjectDataSource supports .NET Standard projects. We have tested it with .NET Standard 2.0.
Regards,
Todor
Progress Telerik

I tried creating a report inside Visual Studio 2017. I have .Net 4.6.1 class library with my report. This class references Telerik Reporting 12.1.18.516. I was able to create a report with an ObjectDataSource that talks to a .Net Standard 2.0 class library as you suggested. When I click on the preview tab I get a "Could not load type" exception with the name of the obect in my .Net Standard 2.0 class library.
I have the following on the App.config for said class library.
<
Telerik.Reporting
>
<
assemblyReferences
>
<
add
name
=
"Payroll.Core"
version
=
"1.0.0.0"
/>
</
assemblyReferences
>
</
Telerik.Reporting
>
I tried rendering the report on a Asp.Net Core 2.1 website that has .net 461 as the target framework <TargetFramework>net461</TargetFramework>
When I try to render the report (as a PDF) I get the same "Could not load type" exception with the name of the obect in my .Net Standard 2.0 class library. I tried adding an app.config file to the web application with the <Telerik.Reporting> <assemblyReferences> section.
I'm directly rendering the PDF with a code similar to this one:
var telerikReport = new ReportObjects.Payrolls.PayrollInstanceReport();
Telerik.Reporting.Report report;
ReportProcessor reportProcessor = new ReportProcessor();
Telerik.Reporting.InstanceReportSource instanceReportSource = new Telerik.Reporting.InstanceReportSource();
instanceReportSource.ReportDocument = telerikReport;
RenderingResult result = reportProcessor.RenderReport("PDF", instanceReportSource, null);
return result.DocumentBytes;
Is this scenario not supported at the moment under asp.net core, or am I missing something?
I tested the approach locally. It works fine on our side.
Make sure that your .Net Standard 2.0 Class Library is properly referred in the other projects.
I have attached my sample test solution for your reference.
There are three projects:
1. WebApplication2 - a .NET Core 2.1 Application targeting .NET Framework 4.6.1
2. DotNetStandardClassLibrary - a .NET Standard 2.0 Class Library that provides data to the ObjectDataSource
3. ClassLibrary1 - a .NET Framework 4.6.1. Class Library where the report is defined
By selecting 'Viewer' from the main menu you will open the report in the viewer.
By selecting "PDF" you will trigger PDF Export - I have used the provided code.
You can test the sample, compare it with your application, and adjust the latter if necessary.
Note that instead of creating an instance of the Reporting Engine to export the report to PDF you can use our REST Service API where the latter is already instantiated.
Regards,
Todor
Progress Telerik

Thank you for the sample.
After playing around more with this, my problem seems to be with injecting services. I'm using asp.net core and taking advantage of the built in dependency injection. When my injected services get to the report class, on the NeedDataSource which is where I'm populating the data, things like DbContext are not available anymore, it says it has been already disposed. I also have another service, that returns data from the current user principal as well as the request headers, these are null when they get to the NeedDataSource on the report.
Could you confirm if an scenario like what I described is supported under the current version? Is it possible to inject the dbContext and user principal services into the report?
Thanks again.
Firstly, our recommendation is to avoid using events when data binding the reports, except really necessary. In this case I cannot determine why the NeedDataSource should be used, rather than declaratively configure the data source in the report definition.
Anyways, it would be needed to either use the EntityDataSource component so that we can create the DbContext object internally, or create and use DbContext instance in the NeedDataSource event handler. To access the current user context, you can use the Telerik.Reporting.Processing.UserIdentity.Current static property. It is also possible to use the new UserIdentity object in the expression context as a global object: =UserIdentity.
The UserIdentity.Context property can be used to store user objects.
Regards,
Silviya
Progress Telerik

Hello KSafadi,
The Standalone designer is built against .NET Framework 4. However, if your .NET Runtime is 4.6.1 or higher, it will be able to load also .NET Standard assemblies up to .NET Standard 2.0 - check .NET implementation support. According to the same table, .NET Framework does not support .NET Standard 2.1, hence assemblies built against it are not supported in the Standalone designer.
If your Reporting engine is running in .NET Standard 2.1 or .NET Core 3, it should be able to resolve also ObjectDataSource assemblies built with .NET Standard 2.1.
I have attached a sample ASP.NET Core 3 project with REST Service and Html5 Viewer, and .NET Standard 2.1 ClassLibrary to return some simple data for the report. The report successfully displays the data returned by the ClassLibrary project.
We will try to improve our Documentation regarding the ObjectDataSource, Standalone designer and .NET Core/Standard support.
Regards,
Todor
Progress Telerik

Hi Todor,
So are you saying that if you design the report using net standard 2.0 classes, you can then run the report from a report engine running net core 3.1/netstandard 2.1?
Otherwise, how do I design my report when my objects are compiled with netstandard 2.1?
Is the Report Designer going to be updated soon? Otherwise, I'm at a standstill :(
Hi Rick,
Yes, you may use .NET Standard 2.0 classes in .NET Standard 2.1 projects. I confirm that you may run a report with ObjectDataSource that is built with .NET Standard 2.0 in .NET Core 3.1/ .NET Standard 2.1 application.
If your libraries must be .NET Standard 2.1, you may create a dummy data source with the same fields that the original data source has just for design purposes. For example, you may add the same classes in a complimentary .NET Standard 2.0 project that will be used only for designing. Or if there are no collections, you may use a CsvDataSource with the same fields. JsonDataSource is another option. After designing the report you should simply replace the dummy data source with the real one.
We cannot upgrade the Standalone designer to support .NET Standard 2.1 for technical reasons. The designer is a WPF application using the Windows Forms Report Viewer. Unfortunately, .NET Core still doesn't support the necessary design functionality that is available in the .NET Framework.
We have dedicated most of our developing resources for improving the new Web Report Designer. I hope it will soon support the ObjectDataSource.
Regards,
Todor
Progress Telerik

Hi Todor,
I managed to create a simple ObjectDataSource from a .NET Standard 2.0 class library (just a simple list of strings). It works as expected, but as soon as I reference other NuGet packages like EntityFramework 3.1 (which is compatible with .NET Standard 2.0) and create a DbContext the datasources from my library are no longer displayed in ObjectDataSource-Wizard..I can see in the log file that my assembly is successfully loaded. What am I doing wrong?
Regards, stay safe, stay healthy
Heiko
Hi Heiko,
You may check the Assembly Used in ObjectDataSource is Not Loaded by the Standalone Report Designer for hints on tackling the problem.
Regards,
Todor
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.

Hi Todor,
I used Fuslogvw as mentioned in the help article but still: no success! I can't see my datasources even though everything is loaded correctly. See attached screenshot of all assemblies Fuslogvw has logged, looks like everything is related to Telerik, not my assembly. I also checked the logfile of ReportDesigner - also no error, my assembly is loaded just as expected.
What now?
Regards
Heiko
Hi Heiko,
Indeed, from the screenshot, it seems that there aren't any fails in loading custom assemblies.
You may open a support ticket and send us the .NET Standard 2.0 project used for the ObjectDataSource for local investigation.
Regards,
Todor
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.

Hi Todor
I have tried the demo and the VS throws me the following warning:
TS6053 (JS) File 'C: /../ DataObject / Asp.NetCoreDemo / wwwroot / api / reports / resources / js / telerikReportViewer' not found.
and the browser never gets to load the report correctly.
Do I need to add something else?
Cheers
Hi Carlos,
The error on the screenshot indicates that the telerikReportViewer JavaScript file that contains the functionality of the Html5 Viewer cannot be found. Generally, it gets loaded from the Telerik Reporting REST Service that according to the image should be running on https://localhost:44379/api/reports.
Most probably, the service is not working. You may check this with a Get Available Document Formats request to https://localhost:44379/api/reports/formats.
Which version of Telerik Reporting do you use?
You may use Fiddler to inspect the requests to the Telerik Reporting REST Service for more details on the communication between the viewer and the service.
You may also attach a Trace Listener to the service to see the stack trace of the Internal Server Error (500) that is seen on the screenshot. You may check Troubleshooting reporting implementation into ASP.NET Core application KB article for instructions.
Regards,
Todor
Progress Telerik
Our thoughts here at Progress are with those affected by the outbreak.