Hi Adrian,

Apologies for the delayed answer.

Our aim is to preserve the existing code written in the report events like ItemDataBinding() and ItemDataBound() "as-is", so no modifications should be required and your current code will remain functional. So far we haven't stumbled upon problems with the CodeDOM serialization of the report definition  and the report events are executed as expected.

I understand your concern about keeping the already existing user code intact, and we'll do our best to post an example in this thread soon.

Regards,

Ivan Hristov Progress Telerik

Hi Kori,

There you go: Support for custom root designers #4126. The issue is logged in microsoft/winforms-designer private repo, so I'm not sure if you or anyone interested will be able to access it.

The problem is also mentioned in the comments of the Klaus Loeffelmann's excellent blog an year ago. I believe adding a comment there should also help.

All best,

Ivan Hristov

Hi Adrian,

We have dedicated part of our dev force to work exclusively on the Visual Studio Telerik Report Designer, trying to move as much functionality as possible for R2 2023. As far as I know, there's no change in the plans of Microsoft's WinForms team about supporting custom IRootDesigner implementations. 

As I promised below, I will keep you updated about our progress, so here it is: we plan to do a live showcase of our Visual Studio Report Designer during the incoming R1 2023 Release Webinar, which will be streamed this Thursday, February 2 - 11:00 AM - 1:00 PM ET.

Although there is a lot of awesome new stuff for Telerik Reporting, Fiddler, and JustMock, we believe the presenter Rick Hellwege will manage to include a few minutes to preview the current state of the designer. This webinar is also a place to ask your questions and get an answer directly from team members that build and support the product.

If this sounds interesting, I would like to invite you and everyone in this thread to register for the webinar using this link.

See you there!

Ivan Hristov

Hi all, 

I want to share with you the good news about the current state of our Visual Studio Report Designer for .NET projects. In my last post, I explained that our Report Designer relies on specific design-time functionality that is not yet supported by Visual Studio's WinForms designer. Technically speaking, using a custom implementation of the IRootDesigner interface was not possible, and this is exactly what we rely on to build the report design surface.

I'm glad to share that the people at Microsoft's WinForms team have worked on the missing pieces and provided us with a solution. A version of the demo is publicly available in the CustomRootDesigners demo, if you want to have a look. Using this approach, we were able to reuse a significant part of our designer-related code and produce a layout, which is the same as the one produced by our Visual Studio Report Designer for .NET Framework. As an example, here’s how our Swiss QR-bill example report looks like, rendered in the new Report Designer:

And now to the concerning part: at this moment, the possibility to have a custom IRootDesigner implementation is not yet included in Visual Studio’s WinForms Designer SDK. Currently, our code works against a custom branch of Microsoft’s code and we use Experimental instances of Visual Studio 2022 to make it run. Based on our communication with the MS WinForms Designer team, it seems unlikely to have the needed functionality merged and delivered in a Visual Studio 2022 update in time for our R1 2023 release.

Still, we can assure you that we continue the development of our new Visual Studio Report Designer, adding the missing parts and polishing the existing ones. We will use this thread to keep you updated about our progress because we understand the importance of the feature and know how eagerly anticipated it is.

Stay tuned for more good news!

Ivan Hristov

Hello Aldo,

Most likely, the displayed error is caused by the currently used .NET runtime. The Standalone Report Designer for .NET (SRD.NET for short) is targeting .NET 6, because this is the current version of the framework that has Long Term Support (LTS). We decided to not retarget it for .NET 7, because .NET 7 is defined as STS (Standard-Term Support), and also because the users that don't have the .NET 7 runtime installed yet, might not be able to run it.

When deciding what the behavior of our application will be, we were focused on preserving the .NET 6 runtime as default one, due to the breaking changes (especially in the serialization domain), introduced in .NET 7. Still, we wanted to allow our users to load .NET 7+ custom assemblies.

We've configured the application in a way that makes it possible to load .NET 7 assemblies and we can assure you that this scenario is supported. We build SRD.NET with a dedicated property that allows it to be run against future version of .NET runtime: <RollForward>Major</RollForward>. This property ensures that when .NET 6 runtime is not installed, but .NET 7 is available, the SRD.NET will run against .NET 7.

I assume that your machine has both .NET 6 and .NET 7 installed, but since the SRD.NET is executed using the .NET 6 runtime, it cannot load the .NET7 assembly and throws an exception.

Microsoft has provided a detailed description about controlling the RollForward behavior at runtime, so if you need further information, you can check their article here: https://learn.microsoft.com/en-us/dotnet/core/versions/selection#control-roll-forward-behavior

As a solution, I suggest to use the option to start the SRD.NET while setting the RollForward option to LatestMajor from the command prompt like this:

C:\Program Files (x86)\Progress\Telerik Reporting R3 2022\Report Designer\.NET>Telerik.ReportDesigner.Net.exe --roll-forward LatestMajor

As explained here, the LatestMajor option will enforce using the latest .NET runtime, even if the targeted .NET 6 runtime is available. I can confirm this solution works with the official release of .NET 7 and I was able to see and use my .NET 7 custom assembly in the latest version of SRD.NET 16.2.22.1109.

If you're planning to use SRD.NET with .NET 7 runtime, I'd suggest to create a shortcut with the parameter and use this shortcut to start the application.

I will leave the answer here in this thread, although it is not related to the original topic, because I believe it will be useful for our users that want to have .NET 7 support in our report designers. I'd like to thank you for your feedback and I'll ensure this information will be added to our documentation.

All best,

Ivan Hristov

Hi Adrian,

Yes, our plans include supporting .NET 7 projects too. Based on your description, I can suggest to start working on your project, using the workaround mentioned previously in this thread:

To have your reports working in a .NET Core and .NET 5+ apps, put your reports in a .NET Framework class library that will be used only for designing. Then reference the reports as links in a new .NET Core+ class library. Although the reports won't allow designing them from this library, they can be referenced by the other project in your solution, since the library targets .NET Core or later. Later, when we introduce the Visual Studio Report Designer for .NET Core+ projects, you'll just replace the report link references with the actual report files and your project should work as expected.

This way you'll be able to use Telerik Reporting in a .NET 7 applications instead of creating a .NET Framework one.

All best,

Ivan Hristov

Hi Yudiel,

We haven't changed our plans to continue the development of the Visual Studio .NET Report Designer. Some of the problems we've stumbled upon, require additional implementation from Microsoft WinForms team, but I believe we will be able to resolve them in a timely manner and publish a working version with our next release R1 2023.

Regards,

Ivan Hristov

Hi Eman,

I'm glad my post helped.

The bidirectional conversion of reports between the Visual Studio Report Designer and Standalone Report Designer is available for years and the process is described in How to import reports created with the VS Report Designer and How to import reports created with Standalone Report Designer. Reports made with Visual Studio can be imported in the new Standalone Report Designer for .NET and we do not plan to change this - quite the opposite, we have plans to improve the import process. In fact, we've always suggested to use the Standalone Report Designer for report authoring, because of its declarative report definitions which are framework-agnostic. True, the Standalone Report Designer by design does not have event handlers and does not support custom code, but in almost all cases these limitations can be mitigated.

So, to confirm - our plans are to preserve the importing logic from and to Visual Studio Report Designer. You will be able to import your type definition reports from a .dll into Standalone Report Designer for .NET, and you'll be able to import them back to Visual Studio Report Designer for .NET, when it's available. Naturally, all the restrictions imposed by the import process will still be applied. As for the process itself - it's handled by the convenient Wizards in both Standalone Report Designer Open File dialog and Visual Studio Import Wizard, and takes just a few clicks to complete, so I'd say it's far from complex.

Regards,

Ivan Hristov

Hi all,

My name is Ivan Hristov – engineering manager in Telerik Reporting. I would like to share with you what is the current state of the Visual Studio Report Designer for .NET Core and why we did not manage to release it as planned. But first, please take a look at the GIF below:

This is a Telerik Report Designer running in Visual Studio in a project targeting .NET 6. As you can see, there are lots of things working – design surface with rulers and toolstrip, Properties tool window, complex expandable editors for collection objects, and more. Selecting, moving, and resizing the report items is also implemented. We were convinced we are moving in the right direction until we found out that some of the major architectural decisions we made at an earlier stage, were not fully compatible with the new Visual Studio WinForms designer, resulting in poor design time experience and performance issues.

Naturally, we changed our approach to solve these problems, however the Visual Studio WinForms designer for .NET Core is brand new and while Microsoft had done a great job with it, at this point of time it seems that its capabilities are not yet on par with the full framework designer, especially for the complex integration that Telerik Reporting has with it.

The good news is that the awesome team at Microsoft was already planning to introduce support the integration that we rely on, and we’re currently closely collaborating with them, trying to find a resolution.

However, we did not stop there as we wanted to still be able to allow our clients create reports, using their .NET Core business layer. Therefore, we managed to rebuild the Standalone Report Designer targeting .NET 6. Although it still has some limitations, which we will address in future releases, this approach can be used in the interim to create reports. We also will soon share resources on how this Standalone Report Designer can be used as a workaround to edit existing compiled reports for that people that have urgent need to do that and cannot wait for the Visual Studio Report Designer to come to life.

With this rather long post, I hope I managed to explain what problems we stumbled upon while implementing the Visual Studio .NET Core Report Designer and how we tried to solve them. We understand how important it is to you and we’ll continue working on delivering a fully-featured and reliable Visual Studio report designer. We will make sure to send updates in this thread as we have them.

On behalf of the whole Reporting team, I would like to thank you for your patience and understanding. As always, you are more than welcome to share your thoughts and we’ll be happy to answer.

Hi Adrian,

Our engineering team members are putting their hearts into this feature and I am confident we will have the core functionality released in mid-September. What will be most probably missing are more or fewer popup editors as each one of these requires explicit wiring and its development time accordingly. You would be able to use the Property grid toolbox instead for most of the functionality.

Regards,
Milen
Progress Telerik

Hello Ade,

Thank you for sharing your feedback with us.

Here you can find some articles that are related to connecting to Entity DataSource:

- Connecting to an Entity Data Model with the EntityDataSource component

- Use Telerik Reporting in .Net Core with Entity Data Model

Regards,
Neli
Progress Telerik

Hi Aldo,

I agree that the VS designer coverage of .NET Core/5/6/7 projects is fundamental and gradually became a must along with the high .NET adoption. This is why we started R&D on this task back in the R2 2021 release cycle (~14 months ago) and committed to providing updates on the progress.

Milen

All,

Thank you for expressing your concerns about that feature. I completely understand your pain and want that implemented no less than you all. Still, I will have to announce that it is still not ready for release despite our efforts. Stay tuned to this thread as I will announce here our progress. We are targeting now the R3 release due in mid-September. Thank you for being our loyal customers. 

Regards,
Milen
Progress Telerik

Hello Deepak and all,

It is the last thing I would like to announce, but the designer will not make it in the January release. We have solid development on that feature but we did not manage to implement all the editors and design surface functionality in the new VS designer paradigm. It just appeared the scope and complexity of the implementation exceeded our expectations. That said, it is still not ready to serve you, our users. I am rescheduling it for the mid-May release which I sincerely believe is an achievable milestone. Meantime please refer to this workaround to be able to edit CS reports and use them in your .NET Core 3+/.NET 5/.NET 5 projects. Sorry for the inconvenience.

Regarding the particular question, Deepak, yes, the designer targets both VS versions 2019 and 2022.

Have a great year all of you,

Milen
Progress Telerik

Hello all,

It is our process for an item to go through Under Review -> Unplanned -> Planned. Apologies for the misunderstanding. Having in mind the technology trend and the votes for this feature it is one that we will put serious effort into to release in R3 2021.

Regards,
Milen
Progress Telerik

Hello all,

Our plans do include it for 2021. We will post an update once we have a more granular estimate.

Regards,
Todor
Progress Telerik

We are keeping a close eye to the efforts of the .NET team that works on the Windows Forms designer on .NET Core. Yesterday they've introduced a preview version of the designer - it looks promising, but there are still lots of missing features. For example, containers, resources and component tray are not yet supported, and they are mandatory for our reports designer. We are sure that the subsequent versions of .NET Core Windows Forms designer will add the missing features, but its current state is just not fit for our needs. Please rest assured that we understand how important this designer is for our clients and as long as it is released with all the necessary components, we will do our best to include it in the next version of Telerik Reporting.

Regards,
Ivan Hristov
Progress Telerik