Make Visual Studio designer work with .NET Core (a.k.a. SDK-style) projects
At the moment it's only possible to have your reports in old-fashioned projects.
It should be possible to add/design reports to SDK-style projects. That should work no matter what target framework is (.NET Core, .NET Standard or .NET Framework).
109 comments
Adrian
Posted on:12 Dec 2024 11:11
Any updates before Christmas?
ADMIN
Plamen Mitrev
Posted on:28 Oct 2024 13:07
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.
So what would the timeline/s be now for the 2 different ways to run these reports?
The full vs designer with code behind.
The deserializing of the tdrx files and then referencing them as you have detailed in the post dated: 20 Jun 2024 10:44
Regular updates would help us plan for upgrading existing projects.
Adrian
Jeremy
Posted on:14 Oct 2024 07:20
I'm thankful I read this thread as my client refuses to allow .net framework on their infrastructure.
As per Adrian's comment I will need to look at competitor's products.
Bit of a shame
Adrian
Posted on:09 Oct 2024 10:59
Is there are more progress with this?
I have had to move on with competitor's reporting product (provides vs designer/code behind support) as one of my customers is pushing to start a new project (dotnet 8 winforms, mobile & web) before the end of October and wanted workable reporting in the prototype.
Am also starting a couple of upgrade projects in the new year (dotnet 4.8 to .net 8/9). I cannot delay them any further than that and will have to asses what to use at that point in time. Whether to be able to reuse or re-create the reports from scratch again.
Adrian
Eric
Posted on:02 Oct 2024 19:50
FIVE AND A HALF YEARS. Brutal.
ADMIN
Ivan Hristov
Posted on:22 Aug 2024 15:47
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
Aldo
Posted on:07 Aug 2024 08:14
Perhaps someone has not yet realized that the workaround will in fact be definitive : there will never be a VS designer for .Net 6+!
This thread is getting close to being 6 years old, it's impossible not to even have a beta version, just some unknown screenshots.
As Alexander said, this is simply a bait and switch, to prevent customers from changing reporting tool.
After 6 years, now, we should start a discussion to choose the less impactful workaround...really bad handling of this problem.
ADMIN
Milen | Product Manager @DX
Posted on:25 Jun 2024 12:31
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.
I agree with the folks below who would rather use the workaround until we get the VS Designer, rather than using the Standalone Designer.
Andrea
Posted on:21 Jun 2024 20:26
Hi,
totally agree with Deepak and Alexander. I also prefer to use Net Framework designer workaround. I have almost 100 reports in production and I don't want use standalone designer. Thank you.
Deepak
Posted on:21 Jun 2024 18:44
100% agree with everything that Alexander just said!
I'd rather wait until you get the Visual Studio Designer done and continue using the workaround (target .NET Framework and .NET 6/8 in the same project) rather than switch to the standalone designer.
Alexander
Posted on:21 Jun 2024 17:44
I'm sure for many, the need for event handlers is important. But for us, we chose to use Telerik Reporting for our new project because of it's ability to integrate with VS. This provides so many benefits in our experience:
Being able to easily see what classes a report references
Searching & refactoring are considerably easier
Source control -- trdp files are useless in a git diff
Not having to keep assemblies in sync with an external editor: - Not having to switch between editors when you need to add a new data element and then rebuild. - Not wondering if you made a mistake or if the assembly is just out of date in SRD.NET. - Building & publishing your app is safer because its all in-IDE, the files can't get out of sync
We are a small team, and in 2 years we've developed an entire enterprise application from scratch with over 100 reports using the (cumbersome) workaround. I've been watching the progress on this feedback item for years hoping for it to happen before we release our app. Well, we are launching next month and we are still using the workaround.
The application we are launching is a ground-up re-write of a legacy application -- so believe me when I say that I understand the struggle with adapting a legacy codebase to new tools. But abandoning the VS designer support passes that burden onto your customers and it feels like a complete bait-and-switch. We likely would not have used Telerik Reporting if we knew this wouldn't be an option.
For my team, we would rather continue using the workaround while we wait for a solution that keeps all of the above benefits. That is why we picked Telerik Reporting in the first place.
Deepak
Posted on:21 Jun 2024 16:11
Hi Ivan,
Having all the Reports in .CS format is definitely more ideal for me rather than .trdp or .trdx.
Is it possible for the new Designer to save the Reports in .CS format?
Will I have to convert all my existing .CS reports to .trdx to use the new Designer? If so, how would I do that? I have over 100 Reports!
Regards.
Deepak Gupta
ADMIN
Ivan Hristov
Posted on:21 Jun 2024 15:43
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
Deepak
Posted on:20 Jun 2024 13:39
@Ivan,
May I know what is the format for the .trdx / .trdp report definition files? If they are compressed zip files, then I won't be able to search within them whenever I do a solution-wide search for Method / Class names.
Deepak.
ADMIN
Ivan Hristov
Posted on:20 Jun 2024 09:44
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);
}
publicasync 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);
}
privateasync 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";
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
Adrian
Posted on:14 Jun 2024 13:20
Hi Ivan
Would it be useful to showcase how example reports in the original dotnet framework, using some of the typical approaches we use (and have sent to you), and how you would see it being done in .net 8+?
Regards
Ade
Deepak
Posted on:13 Jun 2024 10:08
Hello,
One of the best things that I like about the integrated IDE within Visual Studio is that all the Reports are in .CS files. For my LOB apps, I create 1 Visual Studio solution with the following types of projects in it:
* SQL Database Projects (SSDT)
* C# Data & Business Layer Class Libraries
* C# Telerik Reports Class Library with Object Data Sources from the Data & Business Layer Class Libraries
* C# ASP.NET Web Project (with Controllers and Script files)
This helps me have all my source code in 1 place. So if I ever need to do any kind of refactoring on my Class Libraries, it is very easy for me to search across all the source code. Having all the reports in separate .trdp/.trdx files will severely limit this functionality!
Regards
Deepak Gupta
ADMIN
Ivan Hristov
Posted on:12 Jun 2024 16:17
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
Steve
Posted on:05 Jun 2024 22:08
Why not just keep the current report designer with all reports contained in a .NET Framework 4.8 project, but allow it to connect to .NET6+ datasources? Would this work?
Adrian
Posted on:05 Jun 2024 13:49
Thanks for the update.
As an example of some of the reporting i deal with with one of my newer customers for .net framework winforms.
Their reports are called using dependency injection (along with all winforms, and data access repositories), either in the forms constructor or ServiceProvider.GetService<type>
So in the report its initialize then an async method (LoadData below) is called to pass it the data
So if I understand correctly, we will have to convert all the reports that have been created with the Visual Studio Report Designer to use the Standalone Report Designer, refactor all of those (more than 100 reports in our case), and than when we modifiy them or create new ones we have to reimport them in the solution?
How is this the best solution to this feature request?
ADMIN
Ivan Hristov
Posted on:05 Jun 2024 12:56
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
ADMIN
Ivan Hristov
Posted on:30 Apr 2024 12:45
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
Eric
Posted on:23 Apr 2024 15:06
Three months without so much as an update?
Adrian
Posted on:23 Apr 2024 14:50
I see the Q2 2024 release webinars are already showing on your website.
Will the designer be ready for that release as it is not mentioned at all in the q2 2024 details so far?
Ade
Adrian
Posted on:14 Mar 2024 11:08
An update would be great as i am currently looking at a mobile app project that has a need for reporting.
Eric
Posted on:05 Mar 2024 17:50
Any update on this?
Kori
Posted on:22 Jan 2024 14:37
That's good to hear Ivan (about the continuing work, not the change in internals at MS). Please keep us updated on the expected timelines. While the workarounds enable us to continue, they are significant to maintain and every time there's a new report or an update it's pretty painful to upgrade.
Looking forward to when this is finally released.
ADMIN
Ivan Hristov
Posted on:22 Jan 2024 14:12
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
Adrian
Posted on:15 Jan 2024 15:24
Any further news on how this is progressing and hopefully any timescales?
Ade
Aldo
Posted on:19 Dec 2023 11:55
Guys, this thread is near to be 5 years old, and we still have no answers...
Adrian
Posted on:16 Nov 2023 12:44
Dot net 8 is out and the VS2022 Preview is now 17.9.
Any movement from Microsoft on the key parts of vs2022 needed to finish the reporting and will it be part of the 17.9 release run?
@dymtro, how does that work (not using net7.0-windows) when the designer includes System.Windows.Forms?
Kori
Posted on:24 Oct 2023 13:53
Will try multitargeting. Right now, the workaround using the link actually makes the designer break - my guess is because of the same name.
ADMIN
Milen | Product Manager @DX
Posted on:29 Sep 2023 10:05
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
We have been waiting for this feature before upgrading our current version. Can you confirm that this is now fully functional with .NET 7?
Regards
Steve
Adrian
Posted on:19 Sep 2023 14:22
I just received the email for the R3 2023 Release Webinars for 18th Oct 2023.
It does not mention about the report designer in the highlights, so will it be released or are we looking at another delay to 2024?
Adrian
Adrian
Posted on:11 Sep 2023 11:28
Just checking on how this is progressing as I am putting together timescales for another customer of mine to upgrade their current .net framework winforms apps to .net 7/8.
Regards
Adrian
ADMIN
Ivan Hristov
Posted on:27 Jul 2023 09:44
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.
voila, the designer works. you will still need to make sure that your code is compilable with .NET 4.8 though. You may exclude problematic pieces with #if !NETFRAMEWORK regions.
P.S. As the creator of this thread (4,5 years ago - sic!) I bet we will not see this anytime soon :). Would be happy to be wrong though.
Deepak
Posted on:20 Jul 2023 13:18
This is great news!
Now the only thing remaining is the Telerik Testing Framework...
ADMIN
Ivan Hristov
Posted on:20 Jul 2023 09:46
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
Adrian
Posted on:13 Jul 2023 14:06
Would the release be likely in Q3 2023 or are we looking at Q1/Q2 2024?
Adrian
ADMIN
Ivan Hristov
Posted on:16 Jun 2023 16:36
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
Aldo
Posted on:12 Jun 2023 10:18
Milen, thanks for your update, but this is a tragicomic news.
Also, since the last update, the --roll-forward LatestMajor workaround has stopped working.
Now, running the command Telerik.ReportDesigner.Net.exe --roll-forward LatestMajor we got always this error and we cannot open our reports to change them.
Regards Aldo
ADMIN
Milen | Product Manager @DX
Posted on:25 May 2023 15:10
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.
Am update on how things are going would be great and which release is it expected to be part of as this is still showing as being scheduled for R3 2022?
Ade
Eric
Posted on:18 May 2023 19:29
Hi Ivan,
Is there an update on the report designer?
Thanks,
Eric.
ADMIN
Ivan Hristov
Posted on:08 Mar 2023 17:40
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
Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you
up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Adrian
Posted on:23 Feb 2023 15:39
Hi Ivan
Do you have any examples of the new designer using code-behind to bind tables to data sources, make controls visible/hidden etc?
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
Kori
Posted on:31 Jan 2023 14:44
@Ivan Can you post the link to the WinForm github issue so that we can all put some weight behind to push them?
ADMIN
Ivan Hristov
Posted on:31 Jan 2023 12:27
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
Adrian
Posted on:25 Jan 2023 10:34
Hi Ivan
Now that r1 2023 is out, are you able to give us a more definite timeline for the VS Designer, or is it waiting on the Microsoft WinForms team?
I am putting together a proposal for an existing customer, to move all their software to .Net 6/7, so timelines would help.
Adrian
ADMIN
Ivan Hristov
Posted on:15 Dec 2022 11:37
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
Aldo
Posted on:17 Nov 2022 09:29
Thank you Ivan,
your solution works fine.
Aldo
ADMIN
Ivan Hristov
Posted on:16 Nov 2022 10:24
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.
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
Aldo
Posted on:16 Nov 2022 00:01
Hi, after we update our dll, used as object datasource in the standalone report designer (as suggested as workaround) to NET 7, we cannot use the report designer to configure (or change) the datasource.
It crash with this message
We tried to copy dlls into the report designer folder, together with our dll, but nothing works.
We attached the full exception message
Please don't tell us, now that we switch to standalone report designer all our reports to workaround the leak of VS2022 editor, that NET 7 isn't supported...
The example in the article you recommend is rather minimal in scope...
If we assume I am creating a new winforms app in dotnet 7 and have an invoice report that I fill using the data from a sql server db using ef core 7.
The report would either need to have the data passed to it from the winforms app as a parameter in the constructor (or other method), or it would load the data itself after being passed the id for the invoice.
The report would then set the datasource of a table to a list<datatype> and other textboxes (etc) would be filled and manipulated (eg: changing text from INVOICE to CREDIT and change colors, etc)
I don't see a viable way around the issue of using a common data source that does not have to be created using .net std instead of .net 7, so both dlls can see the data (unless I am missing something - apologies if I am)
Regards
Adrian
ADMIN
Ivan Hristov
Posted on:28 Oct 2022 11:08
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
Adrian
Posted on:20 Oct 2022 14:07
Hi Ivan
Will it also support Dot Net 7 as well as this is due out next month?
Had to start a new project using dot net framework instead of Dot Net 6 as the reporting requirement was needed to be confirmed before starting, so hope this does not slide any further.
Adrian
ADMIN
Ivan Hristov
Posted on:04 Oct 2022 15:01
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
Yudiel
Posted on:21 Sep 2022 14:24
Hello Ivan,
Thank you for all this information. Do you have any estimate on when this feature will be released?
Thank you,
Yudiel
ADMIN
Ivan Hristov
Posted on:21 Sep 2022 14:15
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
Eman
Posted on:21 Sep 2022 12:33
Hi Ivan,
Thank you for your detailed explanation; really appreciated.
I have just one concern which is still not very clear for me. If we decide to start using the Standalone Report Designer targeting .NET 6 to create reports for now, when the .NET Core support for the Visual Studio Designer is out, would we be able to use the VS Designer to edit and maintain these already created reports (from the standalone designer)? If there is a transition process, how complex would it be?
Thank you once again, Eman
ADMIN
Ivan Hristov
Posted on:21 Sep 2022 11:39
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.
All best,
Ivan Hristov
Reporting Team
Yudiel
Posted on:19 Sep 2022 14:58
Same for me. I have been waiting a long time for this update.
Eman
Posted on:16 Sep 2022 14:19
Any updates on this please? Having the same issue as Adrian.
Adrian
Posted on:15 Sep 2022 15:17
Hi Milen
What has happened with this?
I did the update and it does not allow me to create and design reports in dotnet 6??
It is still showing in the roadmap for the reporting and the release only states .net 6 as being supported in the standalone designer?
Adrian
ADMIN
Milen | Product Manager @DX
Posted on:05 Aug 2022 09:38
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
Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you
up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Adrian
Posted on:02 Aug 2022 13:32
Hi Neli
Just wondering if this is still expected as part of the q3 sept 22 release?
Regards
Ade
ADMIN
Neli
Posted on:15 Jul 2022 11:24
Hello Ade,
Thank you for sharing your feedback with us.
Here you can find some articles that are related to connecting to Entity DataSource:
Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you
up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Adrian
Posted on:08 Jul 2022 10:03
Hi Milen
I think the issue is that the workaround and the code example "VS Designer Core" needs to include an example of the report consuming data in the code behind (using entity framework for example) in both the designer supported class library (dot net 4.8) and the net 6 class library.
eg: passing in a list of data through a public method in the report's code behind and binding it to a table, or the report itself accessing the data itself.
Ade
ADMIN
Milen | Product Manager @DX
Posted on:14 Jun 2022 12:49
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.
The technical reality is that the designer has a huge code base which we need to adapt to the new visual designer architecture that Microsoft introduced. We're continuing to refactor our design-time code, splitting it to fit that client-server architecture. This part of the process is the foundation of the design-time support and cannot be partially released. The main part of our development capacity is currently dedicated to this feature, which makes me believe we will be able to have it released in R3 2022. Even if not 100% functional, we will make sure to have the core functionality in place, while, for example, some specific editors might still not be available.
Meantime, we can try helping with the difficulties you experience implementing the proposed workaround with a parallel .NET Framework library. Others could have such as well. Let's help the community.
Our ultimate goal is to have the same seamless experience when you open your .NET Framework reports in the new .NET Core Visual Studio Designer, so no "porting" or "converting" would be necessary.
Thank you for understanding.
Milen
Aldo
Posted on:13 Jun 2022 08:42
Hi, is it possible to have some updated information about the estimated date for this FUNDAMENTAL feature ?
We cannot wait for it anymore, we have project that need to port a lot of report and actual workaround can't be a way.
If we have to do a lot of work to maintain those reports, we prefer to move to another product, because we're near to NET 7 release and is unacceptable that the report designer still does not work with NET Core/5/6/7.
Please give us a sure and reliable answer.
Regards Aldo
ADMIN
Milen | Product Manager @DX
Posted on:28 Apr 2022 09:14
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
Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you
up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Jon
Posted on:21 Apr 2022 10:44
I was also wondering
We have also projekts that we want update and waiting for update of reporting
best regards
Murat
Adrian
Posted on:21 Apr 2022 10:41
Hi
I was wondering if this will make the release for next month?
The work around does not quite work for how a lot of the reports have been created in some of the projects.
I have a number of projects looking to upgrade to dotnet 6 as part of their next major upgrades and wanted to make sure this is in place first.
Many Thanks
Ade
ADMIN
Milen | Product Manager @DX
Posted on:06 Jan 2022 12:15
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
Brand new Telerik Reporting course in Virtual Classroom - the free self-paced technical training that gets you
up to speed with Telerik and Kendo UI products. Check it out at https://learn.telerik.com/.
Deepak
Posted on:04 Jan 2022 14:08
Hello,
Glad to see that this feature is scheduled for R1 2022.
Just 1 follow-up question. Will the new Report Designer for .NET 5/6 work with Visual Studio 2019 or 2022 or both?
@Deepak I think that's simply because there's no need to release new versions now that the APIs are sorted out and all the bad juju was refactored.
".NET 5 and all future versions will continue to support .NET Standard 2.1 and earlier" from here so that'll work long enough for Telerik to get their act together [hopefully].
Deepak
Posted on:23 Oct 2021 00:27
We use exactly the same approach that Kori described. It works. However, our common code is limited to .NET Standard which prevents us from using any of the newer C# features that are specific to .NET 5 or later only. .NET Standard is now around only for backward compatibility purposes. It has no future. So the sooner we get the .NET Reports Designer, the sooner we can get rid of .NET Framework and .NET Standard from our Visual Studio solutions.
Kori
Posted on:22 Oct 2021 15:24
This is the best workaround we personally employ:
Create a .NET 4.8 project called (projectname).Reports.Core
Add nuget references to Telerik.Reporting, Svg, etc
Change the default namespace to (projectname).Reports
Add a report
Verify the report designer shows correctly, add _anything_ to the report
Create a .NET Core/.NET 5/.NET 6 project called (projectname).Reports
Add the reports generated in the .NET 4.8 project as "links" to the NetCore/5/6 project
Add the same .net references (Telerik.Reporting, Svg, etc)
Use the viewer, reference the report in (projectname).Reports
When editing the reports, open the reports in the .NET 4.8 project. The designer works correctly in this context.
Pros:
You can get work done.
Cons:
Depending on how your project is setup, you won't be able to reference your common code unless it's NetStandard.
TLDR; It's like being in the wild west of reporting solutions.
Dmytro
Posted on:22 Oct 2021 11:35
Yeah, this has been open for almost 3 years now. .NET Core come and gone, .NET 5 is in use, .NET 6 is released in 2 weeks. And still we have to do all sorts of jumps through the hoops around Telerik Report Designer ...
Adrian
Posted on:22 Oct 2021 10:59
Any updates on this being released in Q1 2022?
I have a number of projects that we are starting next year that would benefit from this.
Adrian
Deepak
Posted on:30 Mar 2021 15:40
Thanks for the clarification! Really looking forward to it.
ADMIN
Milen | Product Manager @DX
Posted on:30 Mar 2021 05:42
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
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Andrea
Posted on:29 Mar 2021 17:47
Hello, same situation, I'm porting to NET5 a big project with 50 complex reports that use existing entity framework api data layer. Thank you.
Andrea
Deepak
Posted on:29 Mar 2021 16:31
Hello,
We need a way to edit Telerik Reports that directly save as C# files. If the Visual Studio designer for .NET 5.0 Projects is now "Unplanned", then may we know what's the alternative in the future? Using .NET Framework projects is not an option.
Thanks.
Deepak Gupta
Kori
Posted on:26 Mar 2021 16:42
What? This is "unplanned" now? Do you know the terrible workaround that's necessary for this currently??
Deepak
Posted on:03 Nov 2020 14:14
Todor, that sounds great! I'll keep an eye out for more information.
Thank you
ADMIN
Todor
Posted on:03 Nov 2020 10:35
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
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Jon
Posted on:29 Oct 2020 06:44
I Hope this feature comming soon
Dmytro
Posted on:28 Oct 2020 17:19
Well, we need someone from the team to tell us if and when they are planning to work on this issue. The only way for us to make it happen faster is to upvote the feature request. So, guys, please do that :)
Kori
Posted on:28 Oct 2020 15:53
@Deepak
That's where we're stuck as well. All of our reports are heavily customized and just defining them in the standalone designer isn't possible for us because of that.
Deepak
Posted on:28 Oct 2020 15:38
Hello,
Just to give some background. We have over 100 Reports created using the Visual Studio Designer which directly creates C# files for the Reports that integrate nicely with the rest of our projects. For performance reasons, the Reports use ObjectDataSource that directly refer to our Business Layer classes and methods that uses .NET Standard 2.0. However, looks like .NET Standard 2.0 is going to be set in stone so that it's compatible with .NET Framework and .NET Core.
Ideally, we would like to convert all our projects to pure .NET Core 5.0+ and remove all dependencies to .NET Standard 2.0 and .NET Framework 4.8. However, without the updated Visual Studio Designer, we are unable to do that.
Switching to the Windows Desktop or the Web Designer isn't an option for us, is it? I believe those Designers save the Report Definitions only as XML and we already have over a 100 reports that are pure C#. Is it possible to convert the C# files to XML and then edit them in the Windows Desktop or Web Designers?
Regards.
Deepak.
Kori
Posted on:27 Oct 2020 15:04
Is this coming? Anything?
Deepak
Posted on:26 Jun 2020 19:03
I agree that the main goal should be to get rid of .NET Framework. Even .NET Standard will be deprecated along with it. If this can be achieved with .NET 5, then I can wait :-).
Dmytro
Posted on:26 Jun 2020 19:00
Hi Deepak, we also do something along those lines. However, the main point was to get rid of .NET Framework altogether from our product. At this moment, VS Report Designer is the only reason we have to keep that around. For now it looks like, we will not have this feature until .NET 5 is out + whatever time Progress needs to adjust their stuff. So, somewhere February 2021 would be a fair guess. I'm an optimist :D
Deepak
Posted on:26 Jun 2020 17:54
Here's what I've done as a workaround.
Created a Visual Studio solution with the Business Layer as .NET Standard and the Web as .NET Core.
Added a .NET Framework project for Reports (called it ABC.Reports.Design) which has a reference to the Business Layer. This is where we use the Reports Designer.
Added a .NET Core class library project for the .NET Core Reports (called it ABC.Reports) that reference the files in the Design project as follows:
Add a reference to ABC.Reports project within the Web project.
This allows us to then use Visual Studio for the Reports designer and then deploy the .NET Core web project with references to the .NET Core Reports and .NET Standard Business Layer.
ADMIN
Ivan Hristov
Posted on:01 Oct 2019 08:55
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
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Explore the
Telerik Feedback Portal
and vote to affect the priority of the items
Dmytro
Posted on:24 Sep 2019 09:01
Is there any update on this issue? .NET Core 3.0 is already out, but we still cannot switch because our reports require .NET Framework 4.7.2... This does not make any sense, to be honest. I know, I know, we can containerize report projects and so on. But that is too much work just to make Telerik Designer happy.
Currently, the .NET Core frameworks do not support the design time components we need for our Visual Studio Report Designer. Without these components we cannot provide a quality design-time experience. We believe that VS team will gradually fill the gaps between the .NET Framework and the .NET Core, publishing more and more designer classes. As soon as the necessary components become available we will make sure our designer is working when hosted in .NET Core and .NET Standard projects.
Regards,
Todor
Progress Telerik
Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Explore the
Telerik Feedback Portal
and vote to affect the priority of the items