6 Answers, 1 is accepted
Our Visual Studio Report Designer supports only .NET projects. It has dependencies on .NET framework that prevent it from handling .NET Core projects.
Note that Reports designed in Visual Studio Designer are supported in ASP.NET Core projects. Our recommendation is to create the reports in a .NET Class Library (or our dedicated Report Library project type) and reference that library in your report service or viewer project. More information can be found in Asp.Net Core 2.0 forum thread.
Regards,
Todor
Progress Telerik
Telerik Reporting is supporting .Net Core 2.1 or newer versions including 2.2 and 3.0. The recommended report definitions are trdx and trdp that are authored with the Standalone Report Designer. Due to the framework limitations the Visual Studio Report Designer is not supported. For more information on the topic see .NET Core Support
Regards,
Peter
Progress Telerik
Forgive me, but this makes no sense. Your Visual Studio Designer CAN make and compile .NET Core assemblies.
You just need to change the way to create the assembly files and compile them. You already have the c# report files, you just need to use the "dotnet" command line to compile the .NET Core assemblies.
Please implement this feature, the VS Designer is so much better than the stand alone designer.
Thank you,
Karl
Hi Karl,
We are eager to implement this feature as it is required by many users. Generally, our Visual Studio Report designer registers our custom components/types and utilizes the Visual Studio Component Model designer functionality to visualize and edit reports. For this purpose, we need the VS designer support for .NET Core components that is not fully available yet - check Component designer does not display when targeting .NET Core/.NET Standard.
Regards,
Todor
Progress Telerik
Before you suggest your standalone report designer, I should tell you I have several reports with code-behind.
In the absence of a real solution, do you have any suggested workarounds that can allow me to move forward? With support ending for 3.1, is it vulnerable or does the fact that I'm compiling it in .NET Standard 2.0 mitigate the risk?
If there is no solution in sight, I may need to look at this. These days, it seems DevExpress is ahead of you more often than not.
https://docs.devexpress.com/XtraReports/119717/web-reporting/aspnet-core-reporting
Hi Steve,
Indeed, we provide now the Standalone Report Designer for .NET 6. Unfortunately, it handles only declarative report definitions and cannot work with CS reports with code behind.
The workaround you may use while our developers are implementing the Visual Studio Report Designer for .NET is described in the KB article How to use Visual Studio Report Designer to edit CS Reports in .Net Core Projects.
You may follow the thread Make Visual Studio designer work with .NET Core (a.k.a. SDK-style) projects for updates on the topic.
Hi Todor, thanks but I already have that workaround implemented, which I mentioned in my last comment.
Also, you also didn't answer my question: with support ending for 3.1, is it vulnerable or does the fact that I'm compiling it in .NET Standard 2.0 mitigate the risk?
Thanks for the link. Going by how slowly this is progressing, I will be surprised to see a release this year.
Hi Steve,
According to this article - EF Core releases and planning | Microsoft Learn, the target framework for EF Core 3.1 is .NET Standard 2.0 anyway so any vulnerability should also be present in your assembly regardless.
It should not be a problem to use even EF Core 6.0+ with reporting using the approach from the Use Telerik Reporting in .Net Core with Entity Framework Core - Telerik Reporting KB article. The target framework for them is .NET 6.0 and our new .NET Standalone Report Designer should be able to load those assemblies without issue - Starting the Standalone Report Designer for .NET.
Hi Dimitar, thank you for your response but that is not the issue. How do I connect EF Core to a .NET 4.8 project? The only way I know of is via .NET Standard 2.0, which only supports EF Core 3.1.
Which brings me back to my question: is there some other workaround I'm not aware of?
Hi Steve,
My intention with the last reply is that you would be able to use the newer still supported EF Core versions if you used the necessary .NET Core framework and that we do not limit you on that front. I apologize if my wording wasn't clear on that matter.
As far as I am aware, there is no workaround for your scenario besides migrating to a newer target framework where you may use the newer EF Core version. Or you may consider using EF 6 instead.