Hello Adrian,

The latest approach that we are investigating is the use of CodeDOM serializer by Visual Studio, and it is still a work in progress. The initial research was promising and the next steps are to prove if it works in real life. The main effort is scheduled for the sprint in mid January. We should have an idea if that is working sometime in February. 

We will follow up with you in February to share our findings and next steps. 

Regards,
Plamen Mitrev
Progress Telerik

Hi all,

By means of introduction, my name is Plamen Mitrev and I am a Support Lead for Reporting and other products in Telerik. I am familiar with this thread and its development over the years. Even so, I went through all messages from the start and had an extensive discussion with the product manager (Milen) and the engineering manager (Ivan).

I completely understand you, when you are talking about researching competitors that have a version of the Visual Studio Report Designer for .NET (VSRD.NET). Don't get me wrong, I am sad to see that, but I know that your patience is not unlimited. However, I am thankful and hopeful that we are still looking for solutions together and I hope we can deliver the VSRD.NET.

Progress Update

First, I want to acknowledge one of our mistakes. We did not provide regular updates on our progress, when we were researching and developing all of the previous iterations of this feature. I apologize for the lack of information, especially when things did not go as planned. I want to change that and from now on, me or someone from the Reporting team will share an update of the progress at least once per quarter.

As you already know, the latest attempt to deliver this feature and have the VSRD.NET up and running hit a dead end. The major roadblocks we hit were two: 1) The restricted model of the new designer paradigm did not allow to plug-in our implementation of BehaviorService (a fundamental service used to render all the glyphs on the design surface).  2) The hit-testing functionality we were using was not compatible with the out-of-proc designer and would have to be implemented from scratch.

Support Migration and New Projects with Examples and Guidance

Some of you shared valuable feedback regarding the workaround that we provided. We hear that and plan to improve the documentation to include more complicated real-life projects and reports. We will also improve the existing guidance in our documentation, so that you can more easily take advantage of that approach. 

This is still a temporary solution for those of you, who work in the VSRD, but it will also help other users that design reports in the Standalone Report Designer (SRD).

Control our own Future

As I mentioned, things did not go as planned with the previous attempt to develop VSRD.NET. We learned from that experience and understood that we must take control of our own future. We are currently working on a new approach that would allow us to keep the existing design-time functionality and use the CodeDOM serializer provided by Visual Studio to read and write the report definition in a .cs/.vb files.

Commitment

My and the Reporting engineering team's commitment remains the same - to deliver the functionality that our users want and need, in order to continue being successful with our product. 

You should expect to see regular updates from me or the Reporting team, in addition to answering your questions and addressing your feedback. 

Regards,
Plamen Mitrev
Progress Telerik

Hi all,

I agree with Aldo that the thread is much older than we expected, and I'd like to iterate that during these years we went through several attempts to deliver this designer. I strongly disagree with the assumption this is a bait-and-switch. The designer development was handed over to the most talented developers in Reporting team, including some of the people who were involved in developing the original Visual Studio Report Designer (VSRD) for the .NET Framework. I confirm that all the screenshots that me and my colleagues have posted here were from working prototypes. Please check the YouTube link of our 2023 R1 webinar, where Rick Hellwege demonstrates a working version of Visual Studio Report Designer in a .NET 6 project. As we have explained before, that experimental version of Visual Studio never got officially released, leaving us with no options except to start from scratch again. And we did. We are researching possible approaches for de/serializing report instances with the Visual Studio's CodeDOM serializer, which would allow us to detach from the restricted Root designer in Visual Studio. We haven't given up - we know it is important to you and we are looking for a feasible solution. Once we find it, you'll be the first to know.

Along with the efforts of developing VSRD, we continue to innovate and help our users cover their scenarios: We're focused on cross-platform support and we've implemented a new Skia-based graphics engine from scratch; We delivered a new version of Report Server that runs on Linux distros and ARM architecture; We're looking to simplify the cloud-based and containerized deployment and improve our web widgets. There are many directions we know we can deliver value to our clients, and Visual Studio Report Designer for .NET is one of them.

The addition of event handlers in the declarative report definition, along with their design-time support by the Standalone Report Designer should not be considered a replacement for a Visual Studio Report Designer. It is a feature that: 1) extends the agility of the declarative reports; 2) as a consequence, closes the gap between type and declarative reports, enabling lossless conversion between the definition formats. That said, it would improve the conversion process for those developers who convert their type reports to declarative definitions.

Regards,

Ivan Hristov
Reporting Team

Hi, I would like to thank all who entered the conversation. We hoped to provoke such a discussion to get your opinions on our efforts. To understand what would work for you and what not. The end goal is to enable all of you to go forward with the least friction possible so we will consider all opinions. And, the chosen solution should be feasible for us to implement promptly enough, keeping in mind the adoption of .NET.

Please, anyone who can add to the discussion with their scenario, be it compiled or declarative reports, add your valuable input.

Regards,
Milen | Product Manager @DX
Progress Telerik

Hello Deepak,

The .trdx stands for "Telerik Reporting Definition in XML", which means the files are plain XML files and can be opened in a text editor and its contents are searchable.

The .trdp extension stands for "Telerik Reporting Definition Package" - a ZIP-compressed file that contains the XML report definition along with other resources the report might contain - images, data for CSV or JSON data sources, style sheets, etc. In order to search within the report definition, it must be extracted from the ZIP package first. The ReportPackager class might help with this task, though. Please check this article for more info: Packaging and Unpackaging Report Definitions.

Regards,

Ivan Hristov
Telerik Reporting

Hello all,

Thank you for your questions. Will try to answer them below.

@Deepak: This is a nicely structured solution with clearly distinct layers. With the new approach all those blocks should stay as-is, except that your Telerik Reports Class Library should contain the declarative .trdx / .trdp report definitions. It's up to you to organize them the most convenient way. You can have a separate folder containing all the .trdx files, or you can place them next to their .cs counterpart. The main idea is that the actual report processing and rendering will be done using the declarative report definition, so the InitializeComponent() methods in your report .cs files should not be called at all.

@Adrian: Please check the snippet below. This is how we imagine your code will look like when replacing the .cs reports with .trdx / .trdp report definitions. The major difference is that the .trdx definition is deserialized to a Report instance before feeding the data to it. Also, the references to the report items is done through a helper functions that can be adapted further to your needs.

/// <summary>
/// Example method for finding items by their name in a report instance.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="report">Telerik.Reporting.Report instance</param>
/// <param name="itemName">The name of the report item.</param>
/// <param name="recursive">Determines whether the search will be performed recursively in all the Report's children, or just in its immediate descendants.</param>
/// <returns>The first found item.</returns>
static T GetReportItem<T>(Telerik.Reporting.Report report, string itemName, bool recursive = true) where T : Telerik.Reporting.ReportItemBase
{
    return report.Items.Find(itemName, recursive).FirstOrDefault() as T;  
}

/// <summary>
/// Example instance method that uses local Report field.
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="itemName"></param>
/// <param name="recursive"></param>
/// <returns></returns>
T GetReportItem<T>(string itemName, bool recursive = true) where T : Telerik.Reporting.ReportItemBase
{
    return GetReportItem<T>(this.report, itemName, recursive);
}

public async Task LoadData(int id, PoCopyTypeEnum type)
{
    _type = type;
    _data = await _repo.GetPurchaseOrderReport(id);

// Deserializes a .trdx report definition to a Report instance. For .trdp reports, please check the ReportPackager class.    
    var report = new Telerik.Reporting.XmlSerialization.ReportXmlSerializer()
                .Deserialize("POReport.trdx") as Telerik.Reporting.Report;

    await FillData(report); 
}

private async Task FillData(Telerik.Reporting.Report report)
{
    try
    {
        var hdrAdd = await _settings.GetSetting(_usr.AccountId, "COMPHADD");
        var hdrTel = await _settings.GetSetting(_usr.AccountId, "COMPHTEL");
        var hdrFoot = await _settings.GetSetting(_usr.AccountId, "COMPFOOT");
        var hdrCol = await _settings.GetSetting(_usr.AccountId, "COMPCOL");
 
        
        //if (hdrTel != null) txtCompanyContacts.Value = hdrTel.TextLong;
        if (hdrTel != null) this.GetReportItem("txtCompanyContacts").Value = hdrTel.TextLong;
        //if (hdrFoot != null) txtFooter.Value = hdrFoot.TextLong;
        if (hdrFoot != null) this.GetReportItem("txtFooter").Value = hdrFoot.TextLong;
         
        // txtPurchaseOrder.Value = _data.IsSent ? "Supplier Purchase Order" : @"Supplier Purchase Enquiry";
        this.GetReportItem("txtPurchaseOrder").Value = _data.IsSent ? "Supplier Purchase Order" : @"Supplier Purchase Enquiry";

... more code below ...

    }
    catch (Exception ex)
    {
        throw new Exception(ex.Message);
    } 
}

This code should work on your end with the version of Reporting you're currently using - there is no new concept there, we're just changing the way the items are referenced within the LoadData() method.

I hope the information was useful. Let me know if you have further questions.

Ivan Hristov
Telerik Reporting     

Hello all,

Thank you for your feedback! I will try to answer to all the recent questions.

@Algo: We believe the conversion process can be done in bulk, so you won't have to convert the reports one by one. The converter tool now converts all the reports in an assembly, and if needed, we can consider refactoring it to handle a list of assemblies, if that's the case. About the refactoring: if the code in the event handlers does not reference fields or properties of the report definition, it should be used as-is. Last - yes, the declarative reports created by the converter will be your report definitions from that moment. It's not necessary to add them to the solution, but it's highly recommended to include them in your source control system.
I understand your frustration, but given the circumstances, it's the best option we can suggest that satisfies the need for design-time experience and support for event handlers code.

@Adrian: If I understand the example correctly, you're modifying the report definition in the FillData() method. The code in this method references the report model fields, which is one of the impediments I mentioned in my previous post. To work, this part of the code should have to be refactored. First, the report must be deserialized from the .trdp file and then the report fields should be referenced either by name or type. For example, to access the textBox 'txtPurchaseOrder' you can use the .Find() method of the parent report item. Assuming 'txtPurchaseOrder' is in a PageHeader element, you can access it like this: 

var txtPurchaseOrder = (TextBox)pageHeader.Items.Find("txtPurchaseOrder", false);

@Steve: We do not plan to retire the current Visual Studio Report Designer that works on .NET Framework 4+. The problem is that the reports, contained in .NET Framework 4+ assemblies cannot reference (and hence - load) types declared in .NET Core or .NET 6+ assemblies. In other words, if in your scenario you have a list of business objects declared in a .NET 6+ assembly, there is no way to use it as a data source of a report, contained in a .NET Framework assembly.

Thank you very much for your input. It is essential to us because it helps us validate our development ideas and extends the list of scenarios we have to cover.

Regards,

Ivan Hristov
Reporting Team

Hi all, 


I want to post a short update about our current progress on the task. Also, I'd like to get your feedback about a new approach we're considering for solving the problem with the design-time functionality for reports in .NET assemblies. 


As mentioned before, we're having serious problems following the new design-time architecture introduced by Microsoft in Visual Studio. The amount of code that needs to be rewritten has increased to levels that made us question the feasibility of the task. That's why we took a step back and reevaluated what needs to be done, finally summing it down to 3 major problems: 


1. You, our clients, need design-time support that works in a .NET process, allowing us to load assemblies targeting .NET 6+. 

2. You need event handlers attached to the report events, enabling you to programmatically alter the behavior of the processing stage of the report lifecycle. Such events are NeedDataSource, ItemDataBinding, ItemDataBound. 

3. You need a solution that works with your existing reports having event handlers without refactoring the code in the event handler body. 


This may not cover 100% of the functionality provided by Visual Studio Designer, but in our experience, backed up with years of support communication and feedback, we believe these are the top 3 arguments for having a Visual Studio Report Designer. And we also believe that with a reasonable effort we can offer these functionalities out of the Visual Studio environment. 

Our Standalone Report Designer for .NET (SRD.NET for short) covers p.1 out-of-the-box. It is currently targeting .NET 8 and can run against the latest .NET STS and Preview versions, using the 'roll-forward' feature. It can load .NET 6+ and .NET Standard assemblies containing user functions and business objects feeding ObjectDataSource components. 

The architecture of the XML report definition, used by SRD.NET, allows expanding it with additional attributes. We plan to introduce event handler assignments into the XML schema, providing design-time support that should not be inferior to the one available in Visual Studio. The code behind those event handlers won't move - it will still reside in your C# projects that you will compile for the runtime report generation. This addresses p.2. 

P.3. can be covered by evolving the currently available Reports Converter, which creates declarative report definitions from .NET report definitions contained in a particular assembly. The development should preserve the information about the event handlers into the already existing conversion logic.  


Here's how we imagine your journey of migrating to this enhanced declarative report definition: 

1) Using the converter, you will be able to convert in bulk all the existing .NET (.cs/.vb) reports residing in .NET assembly to declarative (.trdx/.trdp) reports along with the event handler hooks. More specifically, those handlers will be serialized in the resulting report definition using only the method name. The actual code behind them stays in your project/assembly. 

2) For the SRD.NET to be able to use the event handlers, you will need to register the .NET assembly in the application configuration file so it will be loaded in the application domain upon start. 

3) Now you will be able to edit the report in SRD.NET just as in Visual Studio Report Designer (and even better, in our opinion). 

4) When you preview the report, the event handlers are resolved from the assembly (using a combination of report name and event handler name), and attached to the current report, instantiated by the Standalone Report Designer. During the processing stage, the event handlers will be called just as they do when previewed within Visual Studio Report Designer. 

5) When the design process is completed and the reports must be displayed in an external application in a report viewer, or rendered in a file using the Report Processor, you will have to register the .NET assembly in the application’s configuration file. 

6) You will have to add the produced declarative (.trdx/.trdp) report definitions to your project and source control systems, and redirect to the declarative reports all the Report Source instances that currently point to the .NET reports. 


We are aware that this approach also contains a couple of impediments, listed below: 

First, the code in the InitializeComponent() method in the .cs/vb report will not be respected any longer. This might be a good thing, as it will allow you to strip down the unnecessary code from the .designer.cs or .designer.vb files. 

Second: you might need to refactor the event handlers code if it is referencing report model fields, e.g. this.textBox1 or this.graph1. The report instance that will be processed and rendered is the one created from the .trdx/.trdp file. The one contained in the .designer.cs / .designer.vb files should not be considered valid, hence no references to it should be made. If you must access a field from the report definition, the recommended practice is to use the processing item instance, passed as a sender parameter to the event handler. If needed, a reference to the report item definition can be obtained through the ItemDefinitionproperty. 

However, even with the work required by the migration process, we believe that providing a converter tool that produces a declarative report definition (.trdp/.trdx) from your .cs /.vb report classes, while preserving the code within report event handlers, is the way to go. Having a solution that depends only on our architecture and codebase makes us more optimistic about delivering it in a reasonably short term. 


As for the users who generate their reports programmatically without using Visual Studio Report Designer, their code will continue working without any changes. The migration journey described above applies only to those users who design their reports in Visual Studio Report Designer and have their report definitions serialized in a .designer.cs or a .designer.vb classes. 


We are sure there are more scenarios we have not considered yet, and this is where we'd like to ask you for assistance. Please share your thoughts on this idea and let us know if it will work on your end or if we are missing something. 



Regards,

Ivan Hristov
Reporting Team

Hi all,

I am writing to share our progress with the clear understanding it is not good enough. The state of the new implementation is far from deliverable.

We have refactored the drawing logic and now we can deserialize and display a report on the design surface in Visual Studio; However, the input events that should be propagated to the server-side logic do not work well enough, even in very simple PoC projects not using Telerik Reporting design-time classes. As a result, lots of designer-native operations like scrolling, resizing, dragging, etc., suffer. The same applies to the context menu and toolbox area that follow a completely new concept in the out-of-process architecture, so we are also expecting some hurdles there. 

We hoped to be able to reuse as much as possible of the old battle-tested code that worked in the .NET Framework Visual Studio Designer. With the new set of APIs that are part of the WinForms designer's SDK we hit blocks in that regard also. The portion of the code that needs to be completely rewritten is growing way more than expected.

We're in contact with Microsoft engineers trying to fix things on both ends, but still, the progress is not where we'd like it to be. To be completely honest, at this point, we're considering other approaches to delivering design-time experience for report definitions created with Visual Studio Report Designer. Our ultimate goal is to deliver a solution that can work with your current C# report definitions and supports attaching Report item event handlers. We will not be able to deliver such a solution for 2024 Q2, but we have developers dedicated to this feature and we're committed to offering a design-time experience that meets your expectations.

Ivan Hristov

Telerik Reporting

Hi all,

The development of the Visual Studio Report Designer is still in progress, but it won't be delivered with our 2024 Q1 release, which is due on Jan 31st. I'd like to ensure you again that we understand the importance of this feature and once we have anything that can be publicly tested, we will announce it here.

Currently we're not only refactoring our code to work with the new designer paradigm of Visual Studio, but we also have to reflect on the continuous improvements made by Microsoft team. I will illustrate it with an example from the latest changes introduced with .NET 8: up until now, the ISelectionService interface that handles the selection on the design surface, was accepting collection of objects for its SetSelectedComponents(ICollection) method. With latest .NET 8 changes, the public API hasn't changed, but internally they type-check the collection and throw an exception if some of its items does not implement the IComponent interface. This change broke a significant part of our logic, because we did not implement IComponent for each selectable item on the design surface. Now we had to make a step back and refactor the inheritance chain of our code to make it future-proof, and also to ensure backwards compatibility with .NET 6 and .NET 7 APIs.

I hope that such changes will be less in the future and allow us to move forward to our goal - to deliver fully-featured Visual Studio Report Designer for your .NET 6+ projects.

Regards,

Ivan Hristov
Telerik Reporting

Hi all,

Thank you for following our development on this initiative. I know that our efforts will serve you well once the designer for .NET comes true. I need to clarify that this is a common initiative between us and Microsoft and unfortunately, it takes longer than expected. To our last understanding, the first iteration of the needed changes in the Visual Studio designer architecture will be released in version 17.9 of Visual Studio 'Preview'. Let me repeat again that this endeavor's success depends on both Microsoft and Progress. They need our input, we need their root designer extensibility implementation. 17.9 will be a preview release, hopefully enabling our integration, but it will take more iterations until it is final. I hate disappointing you all that no bits will be included in R3 2023, but there are plans and there is the business reality. We all are professionals and need to cope with it. Again, every significant advancement will be shared here. We are committed to bringing this initiative to success.

Regards,
Milen
Product Manager for Progress Telerik Reporting & Report Server

Hi Dmytro,

You are right, adding a TargetFramework moniker that is compatible with the .NET Visual Studio designer will allow to use the designer, but - as you've mentioned - the code within must use only .NET 4.8 classes. Also, the references to other .NET Core and .NET 6+ projects will not be resolved, which is a problem if you want to use ObjectDataSource with models from .NET Core assembly.

I understand your frustration about the implementation of this feature, but want to assure you that this task is our top priority along with the .NET 7 rendering support for non-Windows platforms.

Regards, Ivan Hristov

Telerik Reporting

Hi Adrian,

Microsoft team has began changing the classes in WinForms designer that will support our implementation of CustomRootDesigner. Based on our communication, we hope that they will be able to publish those changes in Visual Studio Preview channel until September 2023 and our R3 release will include the Report Designer functionality.

Regards, Ivan Hristov

Telerik Reporting

Hello Aldo,

Thank you for reporting this issue to us.

I can confirm this is a bug introduced with R2 2023 release and affects Standalone Report Designer when --roll-forward option is used. The problem is likely caused by an updated reference to System.Configuration.ConfigurationManager, but we'll be able to confirm that at a later stage.

I can assure you the problem will be resolved for our next release. We'll also be looking for a workaround that will allow you to use the R2 2023 version of Standalone Report Designer against .NET 7 and later runtimes. Once we are sure the workaround works as expected, we'll post it here.

Thank you for your understanding.

Ivan Hristov

Reporting Team

Hi guys,

Thank you for keeping up the conversation and reminding us of the importance of the VS.NET report designer.

The state of the implementation development is not where we want it to be. We are working closely with the Microsoft WinForms team to come up with a working custom root designer integration solution. Unfortunately, the more strict process and revisiting of the initial take on the matter on their side takes more time than we anticipated. This leaves us no option to release the designer with R2. I hope we will have a new update soon.

Regards,

Milen
Progress Telerik

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