Section reports, dotnet 6 and designer

Posted by: John.Reynolds on 20 January 2022, 10:19 am EST

    • Post Options:
    • Link

    Posted 20 January 2022, 10:19 am EST

    Hello,

    I checked the AR 16 documentation but could not find any reference. Currently using VS 2019 and AR 15 in a dotnet 5 project, we have to create a separate dotnet framework project and link to reports in the dotnet 5 project in order to use the designer.

    Is that still required for VS 2022 and AR 16 and dotnet 6?

  • Posted 20 January 2022, 10:24 am EST

    To be clear, this is about section reports, which are the only kind of reports we use.

  • Posted 20 January 2022, 8:20 pm EST

    Unfortunately yes, you still need to create a separate dot net framework project to use the

    designer for code-based SectionReports in ActiveReports 16 and .Net 6.

  • Posted 21 January 2022, 2:45 am EST

    Thank you. Is there any roadmap available - is creating section based reports without the extra project something which will eventually be supported again?

  • Posted 24 January 2022, 5:58 pm EST

    For the time being no roadmap is available. We will let you know if there is any update on this.

  • Posted 2 June 2022, 5:36 am EST

    I don’t understand why this is still a problem. The .Net work around doesn’t work. The purpose of a Code Behind section report is I can write code. If my library that I use for all my code behind is a .Net 6 Core library, it can’t reference that from a .Net 4.72 project that is linked. Why do all the other designers work but the section report designer doesn’t? Can you explain why this is a Microsoft issue?

    To me this is unacceptable. I have been using Active Reports when this was a product from Datadynamics Version 2. All of your documentation and website sales information say that you still support code behind section reports. I pay my money to upgrade again this year and find out that I can’t use it in .Net 6 Core application which I am currently converting my application to. I do not want to be stuck developing code using old tech.

    I almost feel like you are trying to phase out section reports without telling everyone you want us to switch. I would switch to rdl reports if you had an easy way to convert my many section reports to that format… even if it was just the design.

  • Posted 2 June 2022, 7:49 am EST

    I don’t know if this helps, but we have dotnet core 6 projects which work OK using the method suggested in the help documentation.

    We did two things. First, we created a dotnet 6 class library, and that’s where all of our reports are stored. Our main dotnet 6 projects (usually razor pages or MVC or console) then reference that compiled DLL. We did this to shield our other projects from the NuGet carpet bombing abomination and conflicts from their dozens of required packages.

    The second thing is - as you know - you can’t edit the design in a dotnet 6 project. So we create a second dotnet framework project as described in the help file, solely for linking to the dotnet 6 active reports project reports. In the AR help PDF file it’s page 1251 titled, “Designing Code-based Section Reports in .NET Core”. We follow those steps, and then when you need to use the designer, you double-click the linked report in the dotnet framework to edit the designer. You still edit the code from the original.

    This has worked fine. It’s completely less than great for us, considering every single report we’ve ever written is a code-based section report. I’ve never been given a technical answer as to why this is required, but AR blames it directly on Microsoft.

    Oh, and the stand-alone report designer doesn’t allow me to edit the code-based section reports. I though that would be an “out”, but no joy.

  • Posted 5 June 2022, 9:37 pm EST

    Hello Cory,

    We are waiting for issue https://github.com/dotnet/winforms-designer/issues/4126 (private Repository) to be fixed. We are expecting this issue to be fixed in Visual Studio 2022 17.4/17.5 or 17.6. Once this issue has been fixed we will require few months to complete and verify everything. So the current ETA for this is about ActiveReports 17.0 or later versions such as ActiveReports 17.1/16.3.

    Please accept our sincere apologies on the case. We understand your concern. However, we are not trying to phase out Section Reports by any means. Also we are currently working on adding SectionReport designing support in our Web Designer as well.

    As John has mentioned in the above reply, until the integrated section report designer is supported in .Net Core applications please refer to the following page of our documentation for designing Code Based Section Reports for your .Net Core application: https://www.grapecity.com/activereportsnet/docs/latest/online/designing-code-based-section-reports-in-net-core.html

  • Posted 8 February 2023, 2:48 am EST

    Hi,

    code-based SectionReports didn’t work in ActiveReports 17.0.0 and .NET 7!

    Is there any roadmap for this request available?

    Thank you.

  • Posted 8 February 2023, 7:19 pm EST

    Hi Alexander,

    Currently there is no road map available for this. We are estimating to introduce a Code-based Section Report Visual Studio integrated designer for .Net core in ActiveReports 18 at the end of this year or next year.

    For now, I would suggest you to use the following workaround for designing Code-based Section Reports in .Net Core environment: Designing Code-based Section Reports in .NET Core | ActiveReports 16 .NET Edition

    Or just switch to Xml-based Section Reports(.RPX)

  • Posted 29 May 2023, 12:49 pm EST

    Is this still a problem with AR 17?

  • Posted 29 May 2023, 8:04 pm EST

    Hi Cory,

    Unfortunately yes, as I have mentioned in my previous reply we are estimating to introduce a Code-based Section Report Visual Studio integrated designer for .Net core in ActiveReports 18 at the end of this year or next year.

    Regards,

    Akshay

  • Posted 12 June 2023, 1:43 am EST

    I also feel like GrapeCity is ignoring Section Reports! :frowning:

    My company switched from Crystal Reports to Active Reports. We converted 374 Crystal binary files to initially RDLX and now we MUST switch to RPX for large datasets and I am now wondering if Active Reports was a huge mistake; when compared to Crystal Reports for canned fixed column reports.

  • Posted 13 June 2023, 5:02 pm EST

    Hi Jay,

    Apologies for the inconvenience caused to you due to the unavailability of designer support for SectionReport in .NET 6.

    However, we would like to assure you that SectionReports is not being ignored by GrapeCity and is going to stay for the times to come! Although, we were unable to provide support for the Code-based SectionReport designer in .NET 6 due to a VisualStudio issue that hasn’t yet been fixed.

    However, please be assured that GrapeCity is working on this issue and we’ll introduce a new Code-Based SectionReport VisualStudio integrated designer for .NET Core from ActiveReports 18 onwards.

    For now, if you require to use Code-Based SectionReport you may use the following workaround for designing the same in .NET Core: Design Code-based Section Reports in .NET Core.

    Regards,

    Anand

  • Posted 27 February 2024, 7:07 pm EST

    Hi,

    AR18 was released, but the release notes does not mention any new designer for SectionReports and the documentation still mentions the limitation in the integrated Visual Studio designer in .NET, https://developer.mescius.com/activereportsnet/docs/latest/online/designing-code-based-section-reports-in-net-core.html

    Has there been any progress on this issue or when can we expect a solution to the issue that we cannot design SectionReports in Visual Studio using .NET?

    Best regards,

    Christoffer

  • Posted 28 February 2024, 7:39 pm EST

    Hi Christoffer,

    In brief, the Code-Based Section report depends upon VisualStudio’s CodeDOM (which is under Microsoft’s control) whereas our designer for XML-Based/RPX SectionReport is within our control.

    Unfortunately, we do not have the resources to write everything on our side to load Code-Based SectionReport in VisualStudio and therefore we have to rely upon Microsoft’s out-of-process designer which to date did not have complete component designer support (only WinForms controls are accessible through workarounds)

    As a workaround, we suggest customers use XML-Based/RPX SectionReport (as we have the designer under our control) or use the workaround mentioned here Design Code-based Section Reports in .NET Core.

    For the issue reported to Microsoft: The issue was initially supposed to be fixed in VisualStudio v16.7.0 preview, which got further and further delayed to VS v17.4, 17.5, 17.6 then to v17.8 Preview 1 (September 2023), then to Preview 2: https://github.com/microsoft/winforms-designer-extensibility/issues/23#issuecomment-1670064833, then it was postponed to Preview 3, which theoretically had to have the fix but the issue was not fixed and was expected to be fixed with the release of new SDK which has been released a few days ago on Feb 7th 2024, theoretically it has almost everything and our developers are doing their detailed research on implementing the Designer using CodeDOM with the new changes in place.

    Although there is no fixed ETA for now. However, going through the new changes, implementing them, and getting the code through QA should take approx. ~9 months (if no other bugs are encountered in the process that are not in our control).

    We understand the frustration it has been not being able to use the designer with Code-Based SectionReport through VisualStudio CodeDOM, however, we are meticulously working so we can provide the Integrated Designer for CodeBased SectionReport as it is for .NET Framework if not better.

    We appreciate your patience!

    Thanks,

    Anand

  • Posted 28 February 2024, 8:00 pm EST

    Hi Anand,

    Thank you for the response. We are happy to hear that you are working on it and that there is a plan to get this fixed, perhaps in AR 19. We will have to wait and see.

    Thank you,

    Christoffer

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels