Current filter:
                                You should refresh the page.
                                  • We are migrating our class libraries to .NET Standard in preparation for a move of our server and client host applications to .NET Core. One of the objectives we have completed is the removal of our own WCF services since WCF will not be supported in .NET Core. We use an OData service for all data access so we were never able to utilize your Report Server so we instead built our own "Report Tier" on your ReportService which uses WCF. Do you have plans to migrate your ReportService to .NET Core like you are doing for ASP.NET, WPF and Winforms components?   Your ReportService is a critical component for use due to the power it offers us to bake our own data access solution and deliver reports to various client experiences. Thanks.

                                1 Solution

                                Creation Date Importance Sort by

                                Hi Adam,

                                Yes the WCF functionality is not supported by .NET Core. As the Report Service functionality uses WCF we cannot migrate it to .NET Core. In any case, we are researching a capability of providing some alternative functionality. However, to make any plans we need to collect some additional information on why this functionality is required for .NET Core applications. So, would you please answer the following question to allow us to understand your scenario better:

                                • Why do you wish to use a separate shared app (Server) to generate reports? Have you considered generating report documents in your client WPF application? Note that you can connect a report that lives in your WPF application to your OData services directly, and the report will be generated in your WPF application.
                                • If we replace old WCF functionality with the functionality that uses WebAPI or MVC controllers, will this suit you?
                                • What application you are going to use as a server-side application after migrating to .NET Core? Is it an ASP.NET Core 3 application?
                                • Do you wish to connect the WinForms/WPF report's preview components to this server application? Or maybe you just wish to load exported documents (PDF, Excel, etc.) and print these reports?
                                Show all comments
                                • Adam Caviness 01.10.2020

                                  • Why do you wish to use a separate shared app (Server) to generate reports? Have you considered generating report documents in your client WPF application? Note that you can connect a report that lives in your WPF application to your OData services directly, and the report will be generated in your WPF application.
                                  We must offer many hundreds of reports so having those reports on the client side reduces the speed and flexibility we have in delivering fixes and new reports. Our goal was to have report assemblies only known to our "Report Tier" and offer both web-based (MVC) and thick (WPF) client support in accessing those reports. It has worked well for us. Updating one or two Report Tiers is much easier than updating hundreds of workstations. On another related note, our client application serves many disciplines meeting various state standards so out of those many hundreds of reports, the vast majority are totally useless to any given machine.

                                  If we replace old WCF functionality with the functionality that uses WebAPI or MVC controllers, will this suit you?
                                  Yes actually that was what I was hoping for. We moved the bulk of our data tier from WCF years ago and only had about a dozen left to migrate to Web API. I was actually curious if there were talks there of migrating your ReportService to use Web API. I realize however how much work that would take, your ReportService is quite rich and talkative. I would imagine that talkativeness requires statefulness so a move to Web API would have some breaking changes but I'd gladly migrate. It may also beneficial for you guys since you probably use it in your Report Server offering but I realize it's not trivial.
                                  • What application you are going to use as a server-side application after migrating to .NET Core? Is it an ASP.NET Core 3 application?
                                  Yes, our data tier is ASP.NET Web API running OData v4. Since the OData nuget packages are targeting .NET Standard we'll be able to migrate our data tier to .NET Core. We are of course beholden to you regarding our report tier so it will remain on Framework forever unless another strategy is used.
                                  • Do you wish to connect the WinForms/WPF report's preview components to this server application? Or maybe you just wish to load exported documents (PDF, Excel, etc.) and print these reports?
                                  The former, we use the preview components of the report service.
                                • Vasily (DevExpress Support) 01.13.2020

                                  Hi Adam,

                                  Thank you for you cooperation.

                                  Would you please also clarify why you cannot connect your client WPF application to some API that will supply it with report layouts and data sources. The main idea is to pass your report's layout from your server app to the client. Please refer to the Store Report Layouts help topic to learn how you can save a report's layout to REPX that can be used to pass it from one application to another, and then restore this report back. You can use a custom Web API method to pass your report layouts from the server to client. Then this report can be connected to data directly, or load desired data from your server application. So, the report itself and its data will be loaded from your server, but the report document generation process will be performed in your server-side application. Does this approach suit you?

                                • Adam Caviness 01.13.2020

                                  Yes, I considered this approach originally and decided against it for the following reasons.

                                  1. Additional complexity regarding sub-reports. We make extensive use of sub-reports and they are not supported. We would have to redesign them. In our case, we have hundreds of DevExpress reports that our customers have used for years that are being migrated to a new system so each of those would need a redesign, not just new reports for a new application.
                                  2. It always felt that the stored report approach was best suited to direct data-binding scenarios. At present, code-behind code is needed to query our OData service to set our intermediate models. We could switch this as you suggest and have the client request the report and the data separately and reconstruct on the client but I'm afraid that is a big undertaking.
                                  3. I didn't realize the security implications fully the first time I looked at this but when checking it out again today. I feel we could navigate this correctly without too much friction but it's another element of uncertainty.

                                  All that said, I'm open to it if:

                                  1. It's the only path forward away from .NET Framework
                                  2. It renders reports as quickly or quicker than using the ReportService which is surprisingly fast.

                                  Thank you

                                • Vasily (DevExpress Support) 01.14.2020

                                  Hi Adam,

                                  >Additional complexity regarding sub-reports.

                                  There should not be any issues with using subreports in this scenario if you implement Custom Report Storage in your client application. This storage allows you to resolve reports by using their unique names (report Urls). Each subreport can load a report by this unique name. You just need to update each XRSubreport in your reports to make it use the ReportSourceUrl to obtain report.
                                  And inside your Custom Report Storage implementation just write a code that will load reports by their names from your server application. In case you do not use the End-User Report Designer component in your application, you can skip implementation of the methods that are used to save reports and get the list of available reports.

                                  >It always felt that the stored report approach was best suited to direct data-binding scenarios. A

                                  I assume that you can move your code to WebAPI methods of your server application that will return JSON data. And then you can bind your report to this WebAPI by using the JsonDataSource component. Check the Bind a Report to JSON Data help topic for more information.

                                  >It's the only path forward away from .NET Framework

                                  Yes, with the current version of DevExpress components it is the only way.
                                  At the same time we will research a capability of providing a built-in alternative for report services in the future, but for now we do not have immediate plans on providing this functionality. So, I cannot give you any estimates on when this functionality will be available.

                                  >It renders reports as quickly or quicker than using the ReportService which is surprisingly fast.

                                  It is difficult to answer this question without running performance tests. In any case, I assume that the performance should not become slower.

                                  When you use a report service, all the reports are generated in your server application. Then the generated documents' data is passed to client applications.
                                  When the report is generated in a client application, you need just to pass the report's layout and report's data to the client. Then the report generation will be performed on the client's machine.

                                  Taking in mind these differences, I assume that the second approach may be even faster. This is because the report generation process will be performed on clients, so it won't take the server's resources. The report document may take more memory than the report definition + report data. So, the amount of data transferred among the clients and the server may also reduce.

                                • Adam Caviness 01.14.2020

                                  I feel that you've given excellent support regarding my concerns. Thank you for taking the time to make suggestions and think it through. It is very much appreciated! As you've stated you'll consider what can be done regarding your ReportService I'll also consider rewriting our reporting system. Thank you!!!!

                                • Vasily (DevExpress Support) 01.15.2020

                                  You are always welcome, Adam! I am happy to hear that you appreciate our support services.
                                  Feel free to contact us in case you have any further questions. We will be happy to help you.

                                  By the way, could you please answer several questions regarding applications in which you use our Reporting components?

                                  • For what kind of industry do you develop applications with the help of our Reporting products?
                                  • What kind of reports (table reports, interactive reports, sales reports, invoices, etc.) do you use in your applications?
                                  • Do you consider hosting the server-side part of your application using Linux OS after migrating to .NET Core?
                                  • Do you have any other ideas on how we can improve our Reporting products to make them easier to use in the context of your applications? Do you have any feature requests?

                                  This feedback will help us make our products better.

                                • Adam Caviness 01.15.2020
                                  • For what kind of industry do you develop applications with the help of our Reporting products?
                                  Public Safety and Financial Management industries
                                  • What kind of reports (table reports, interactive reports, sales reports, invoices, etc.) do you use in your applications?
                                  State specific reports, summary reports and a small amount of table reports
                                  • Do you consider hosting the server-side part of your application using Linux OS after migrating to .NET Core?
                                  That was a long-term goal yes but only because our industries may be heading that direction due to .NET Core and SQL Server enabling these possibilities.
                                  • Do you have any other ideas on how we can improve our Reporting products to make them easier to use in the context of your applications? Do you have any feature requests? Of course our biggest desire is to prevent rewriting our report tier and continuing using Report Service with .NET Core. Regarding the ReportService itself, support for nullable types would be nice as I had to create my own wrapper. I feel the Visual Studio report designer integration could be improved. I also understand how difficult it is to work within the IDE constraints but I feel there may be some way to prevent the VS report panels from undocking all the time. Thank you!
                                • Vasily (DevExpress Support) 01.16.2020

                                  Thank you for your great feedback, Adam! I shared it with our team. We greatly appreciate it.