As documented slightly comically here: https://www.telerik.com/forums/can-not-for-the-life-of-me-get-a-report-to-run  , and confirmed by other users on that thread, Telerik reporting can be incredibly unintuitive in the configuration steps.

Having just been through the wringer yet again - I just wanted to copy the configuration from one working project to another, and it's taken me about 6 hours of tearing my hair out to get it working, I'm giving some suggestions for improving this. These really are bugs, not features, hence the bug report.

My use case is the HTML5 report viewer running off the REST service in dotNet 6.

(1) Try systematically breaking one component at a time of the configuration, and check that the error message is correct.

eg. in builder.Services.AddControllersWithViews().AddNewtonsoftJson();

if .AddNewtonsoftJson() is left out, we get the error:

Cannot access the Reporting REST service. (serviceUrl = '/api/TelerikReportHandler/'). Make sure the service address is correct and enable CORS if needed. (https://enable-cors.org)

It is almost impossible to diagnose this - there is no reason that error could not indicate that NewtonsoftJson is not available. I working it out by going through the white paper, and thought 'that's in there but it's surely not going to fix that error message' but I added it anyway and hey presto, fixed.

Another example, not having the .css file referenced correctly in the HTML file referencing the viewer template, displayed a message telling me that the report viewer did not match the REST service version number, a completely incorrect error. Again, I realised the error, thought 'there is no way this is going to fix it', and it did. That's how misleading the errors are.

(2) Don't cache everything

Once I finally got it all working, I decided to break things deliberately to get the error messages so I could record them for my information next time I have to go around this loop. However, I then found that nothing on the client side could be broken. That .css file that was missing a minute ago and causing the error, now I could delete it completely and the reports ran just fine. I could delete the entire template folder and same behaviour, even after closing and restarting the project.

So clearly, once it's working your code is caching the files and/or config internally somewhere. That's a really, really astoundingly bad idea.

The reason I had all these problems in the first place was that I copied all the configuration code and files from a working project, and then the project I copied it to didn't work. I triple checked everything. No go.

I now realise that the working project had probably cached all the files it needed, but then I must have updated the project with non working files, but the project ignored all that and continued to work with its cached files. When I copied the files to a new project, only then did the problem become evident. This is incredibly unintuitive, frustrating and undocumented.

Telerik is not a bad product, but I have never failed to take less than half a day every time I have needed to change anything. If I thought the competitiors were any better, I'd jump ship but frankly I think they're all probably the same.

But if you took this advice, the process would become way, way easier to work through. All we need is good, clear, specific error messages and, for the love of god, *no* caching.