Consider decoupling the request for the report from the process of generating & loading/sending the result for access by the user.
The report request can be done by your asp .net core app by writing the request (report, parameters, export format, printer, email...) to a database or to a file in a queue folder.
The report generation can then be handled by a separate app that you write or by an existing 3rd-party tool. For Crystal Reports, here) is a list of such 3rd-party tools. Some of these already have utilities for monitoring report requests via database or folder queues.
Depending on your scenario, the output can then be printed, emailed, or exported to various file formats (pdf, html, excel, ...). Your .net core app can load these exported files for viewing by the user or simply see the request as completed.
One downside of this pattern is that the user can't interact with the report on screen using Crystal viewer features such as drill-down and on-demand subreports. However, similar functionality is offered by some of these 3rd-party tools with some export formats (pdf drill-downs, html drill-downs, excel auto-filters, pivot tables, slicers...).